Pith. sign in

REVIEW 3 major objections 5 minor 3 references

Lazarus Group Targets Crypto-Wallets and Financial Data while employing new Tradecrafts

T0 review · 3 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read A six-stage LinkedIn-to-Bitbucket attack chain targets crypto wallets with a new Tor-over-IPC backdoor.

desk verdict Genuinely new tradecraft in a detailed six-stage malware analysis, but the Lazarus attribution is TTP-overlap inference with a provenance gap. read the letter →

arxiv 2505.21725 v2 pith:IX7CJFV3 submitted 2025-05-27 cs.CR cs.OS

Alessio Di Santo This is my paper
classification cs.CRcs.OS
keywords LazarusGroupmalwareanalysiscryptocurrencywallettheftkeyloggerclipboardmonitorTor-over-IPCTsunamitoolsetsix-stageinfectionchain
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This report claims that a six-stage infection chain, opened by a fake LinkedIn job offer and a malicious Bitbucket codebase, is a Lazarus Group campaign aimed at cryptocurrency wallets and financial data. It identifies two pieces of tradecraft that the author says are new for this actor: a Python keylogger and clipboard monitor named mlip, which harvests private keys and 12/16/24-word mnemonic phrases, and the Tsunami toolset, whose installer routes command-and-control traffic through a locally running Tor proxy. The report walks through each stage, from obfuscated JavaScript that harvests twenty browser-extension wallets, through credential stealers and an AnyDesk backdoor, to a .NET installer that disables Windows security and talks to a .onion server. If accurate, defenders gain early-stage detection hooks for the recruitment lure, the wallet-extension harvesting, and the Tor-based command channel before wallets are drained.

What carries the argument

The load-bearing mechanism is the six-stage infection chain itself, with the Tor-over-IPC design as its most novel link. In the Tsunami installer (Runtime Broker.exe), a .NET DLL orchestrates the operation: it disables Windows security, drops and starts a Tor proxy, and sends all command-and-control traffic through the local SOCKS port 9050, so that even inter-process traffic is anonymized and looks like ordinary Tor activity. Earlier stages are protected by a repeated 50-layer obfuscation routine that reverses, base64-decodes, and decompresses each payload before execution, and by the hardcoded C2 endpoint at port 1224 used for data exfiltration. The report uses these structures to connect the stages: the same obfuscation function appears in the Python droppers, the same host identifiers recur, and the same RuntimeBroker.exe naming pattern is reused for persistence.

What would settle it

Run the reported RuntimeBroker.exe in a clean sandbox and check whether a child tor process actually launches and sends traffic to localhost:9050; if the binary instead uses named pipes or direct sockets, the paper's central new-tradecraft claim collapses. Separately, if the paste-site-hosted 'cat-video.mp4' archive or the initial-access writeup can be shown to be fabricated, the six-stage chain still stands structurally, but the Lazarus attribution loses its foundation.

Watch

Extended reading notes

Core claim

On the paper's own terms, the discovery is a single, modular, six-stage campaign that starts with social engineering on LinkedIn and ends with a Tor-anonymized remote-access toolset, and the report argues the whole chain is the work of the Lazarus Group. The previously unseen components are mlip, which watches keystrokes and clipboard contents only when the user is in a targeted browser and sends anything that looks like a private key or mnemonic phrase to the C2 server, and Tsunami, a .NET framework whose main executable mimics the legitimate RuntimeBroker.exe process, disables Defender and the firewall, installs a Tor binary, and communicates with a hardcoded .onion address. A distinctive technical choice is the use of the local Tor SOCKS port (9050) as an inter-process communication channel between the parent process and the Tor child, rather than named pipes or shared memory. The report also documents an embedded but unused payload, a set of API endpoints for Discord and browser data, and a whitelisted path for an XMRig miner, which it reads as evidence of an evolving toolkit.

Load-bearing premise

The load-bearing premise is that the LinkedIn and Bitbucket infection narrative is authentic and that matching the techniques of previously reported cryptocurrency-focused malware families BeeverTail and InvisibleFerret is enough to prove a Lazarus Group operation; no direct operator-side evidence such as C2 logs, wallet addresses, or a code-signing identity is presented.

Editorial extensions

If this is right

  • Security teams can hunt for the initial lure itself: a LinkedIn recruiter asking a Web3 developer to run a Bitbucket codebase, followed by HTTP POST exfiltration to port 1224, is an early and identifiable footprint.
  • The documented wallet-extension IDs and Login Data and keychain collection paths give endpoint monitors a concrete file-path and registry checklist for detecting stage-one harvesting before any payload executes.
  • A child process connecting to localhost:9050, a Tor binary living outside System32, or a RuntimeBroker.exe outside System32 becomes a high-fidelity indicator for the new Tsunami C2 channel.
  • Because the Tsunami installer excludes specific paths from Windows Defender and creates a Runtime Broker scheduled task, those two actions are directly actionable detections even if the malware updates its .onion address.
  • The presence of a dormant embedded payload and unused Discord and browser API endpoints implies the toolset can expand into new collection modules without requiring re-infection.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A reader could generalize the Tor-over-IPC finding into a detection template: any process that opens a persistent local connection to a Tor SOCKS port and then makes outbound .onion requests should be treated as a potential C2 channel, even when the parent process is a signed or trusted-looking binary.
  • The attribution case would be materially stronger if future reporting can tie the same .onion address, the same debugging strings, or the same unused payload hashes to a sample with direct operator provenance; absent that, the same evidence could support a copycat or false-flag explanation.
  • The unused XMRig path and the dormant tsunami payload.exe suggest the next iteration of this toolset may add coin mining on high-resource hosts and Discord-token harvesting; defenders can pre-stage detections for those behaviors now.
  • If the report's chain is correct, the social-engineering entry point predicts a broader pattern: attackers will increasingly pose as NFT and blockchain recruiters because the target's browser extension store and clipboard are the actual payload.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The manuscript is a malware analysis report describing a six-stage infection chain that begins with a LinkedIn-based social engineering lure and a Bitbucket-hosted obfuscated JavaScript file, continues through multiple Python payloads (sys info.py, pay, bow, mlip), and culminates in a .NET executable dubbed "Runtime Broker.exe" that embeds Tor and a C2 client. The author presents static and dynamic analysis of each stage, including deobfuscation of a 50-iteration compression/encoding scheme, identification of a keylogger and clipboard monitor (mlip), a browser credential stealer with an embedded payload, an AnyDesk configuration manipulation script, and a persistence/scheduled-task mechanism. The paper concludes that the campaign's TTPs "strongly align" with the Lazarus Group, and that the campaign introduces new tradecraft including the mlip keylogger and the "Tsunami" toolset with a Tor-over-IPC command-and-control channel.

Significance. If the attribution and provenance can be substantiated, the report provides a useful, granular view of a multi-stage cryptocurrency-focused intrusion chain, with actionable detection content (Sigma/Yara rules and MITRE mappings) and a detailed account of a Tor-as-IPC design choice that is uncommon in public malware writeups. The author deserves credit for the depth of static and dynamic analysis, for clearly documenting the deobfuscation procedure, and for being transparent about speculative points (e.g., the dormant embedded tsunami payload.exe, unused classes, and the RickRolling decoy). However, the paper's scientific value is currently limited by the absence of primary artifacts, hashes, or a full IoC list; without those, the analysis cannot be independently verified or reproduced, and the central attribution claim rests on correlational reasoning and a third-party narrative.

major comments (3)
  1. [§4.1, §7] The attribution to the Lazarus Group is the paper's central claim, but it rests entirely on TTP overlap with previously reported BeeverTail/InvisibleFerret activity and on the authenticity of a third-party Notion writeup by Luca Di Domenico. No direct attribution evidence is provided, such as C2 operator artifacts, wallet addresses, code-signing certificates, or unique infrastructure registrant details. As the paper itself acknowledges in §4.2.2 and §7, the observed TTPs are documented as characteristic of Lazarus; TTP matching alone cannot exclude copycat, false-flag, or tool-reuse scenarios. The title's categorical assertion "Lazarus Group Targets Crypto-Wallets" is therefore stronger than the evidence presented.
  2. [§4.1, Appendix A.1] The provenance of the analyzed sample is not established within the manuscript. The initial infection narrative is sourced to a Notion page (§4.1), not to a primary artifact obtained by the author, and the paper does not publish hashes, file sizes, or the Bitbucket repository URL for error.js, sys info.py, bow, mlip, RuntimeBroker.exe, or the later stages. Appendix A.1 defers the full IoC list to an external AlienVault OTX pulse, which is not included in the paper. A reader cannot verify that the deobfuscated code described here corresponds to the sample in the Notion writeup or to the claimed campaign. This provenance gap undermines the reproducibility of the entire chain and should be addressed by providing the raw artifacts or cryptographically strong hashes (and, if possible, the original Notion/Bitbucket links).
  3. [§4.6.3, §4.7] The claim that the Tsunami toolset and mlip constitute "new tradecrafts" is not supported with a clear baseline. The paper states in §4.4.2 that mlip was "first identified only a few weeks prior" to this campaign, but it does not cite the prior identification or explain what makes this version new beyond its presence in this sample. Similarly, the Tor-over-IPC C2 channel is characterized as novel, but no comparison to prior Lazarus or InvisibleFerret communication methods is provided. Without a documented baseline of previously known tradecraft, the novelty claim is not falsifiable. The authors should either provide references to prior observations and explicitly state the delta, or soften the "new tradecrafts" language to something like "previously undocumented in this combination."
minor comments (5)
  1. [§3.2] The dynamic analysis section describes the sandbox environment but does not specify the OS version, analysis tools (e.g., ProcMon, Wireshark), or network simulators used; adding this information would improve reproducibility.
  2. [§4.4.2] The hard-coded C2 IP address and port appear in Figure 37, but the text does not consistently use the same notation; for example, §4.4.3 refers to port 2247 as a remote C2 endpoint while Figure 49 shows commented base64 strings. Clarifying the port-to-role mapping would help readers.
  3. [§4.6.3] The discussion of the unused tsunami payload.exe is appropriately hedged, but the paper does not provide the resource names or offsets used to extract the embedded DLL; including this information would aid verification.
  4. [Appendix A.2] The Sigma rules contain placeholder UUIDs (e.g., '1234abcd-5678-efgh-ijkl-9012mnopqrst') and one rule has 'date: 2023-11-26' while the campaign is dated 2024; these should be corrected.
  5. [Throughout] There are numerous typographical errors and inconsistent names (e.g., 'pay' vs 'pay.py', 'TSUNAMI INSTALLER' vs 'TSUNAMI INFECTER' in §4.4.4, 'ubfuscated' in §4.5.1). A thorough editorial pass is needed.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the Lazarus attribution is an empirical TTP-overlap inference, not a derivation that reduces to its own inputs.

full rationale

The paper is a descriptive malware analysis report, not a formal derivation. Its central claim is that the observed six-stage infection chain belongs to the Lazarus Group, and this claim is supported by correlating TTPs and IoCs with previously documented BeeverTail and InvisibleFerret activity (Sec. 4.2.2, Sec. 7). That is an inductive, evidence-based attribution, not a logical equivalence: the paper does not define Lazarus in terms of this sample, nor does it fit parameters and then rename them as predictions. The newly described tradecraft (mlip keylogger, clipboard monitor, Tsunami toolset, Tor-over-IPC) is extracted from the code itself through static and dynamic analysis, not imposed by the attribution. There are no self-citations, no imported uniqueness theorems, no ansatz smuggled in via citation, and no renaming of a known result as a new derivation. The skeptical concerns about sample provenance (third-party Notion writeup, no published hashes, IoCs deferred to an OTX pulse) are valid reproducibility and verification gaps, but they are not circularity. No step in the paper's reasoning reduces, by construction, to an input assumption. Accordingly, the circularity score is 0.

Assumptions & free parameters 0 free parameters · 5 assumptions · 2 invented entities

The central claims rest on the fidelity of the author's deobfuscation work and on the sufficiency of TTP matching for attribution. No free parameters are fitted because this is an observational report. The new artifacts (mlip and Tsunami) are reported as discovered code rather than theoretical postulates, but they lack independent artifact availability.

assumptions (5)
  • domain assumption TTP similarity with previously documented BeeverTail and InvisibleFerret behavior is sufficient to attribute the analyzed campaign to the Lazarus Group.
    Sections 4.2.2 and 7 assert the attribution based on TTP alignment; no alternative actor hypotheses are tested.
  • domain assumption The displayed code listings and figures are faithful reproductions of the analyzed artifacts.
    The report shows deobfuscated snippets and screenshots but does not include the original samples or hashes, so the reader cannot verify fidelity.
  • domain assumption The LinkedIn and Bitbucket infection narrative reported in Section 4.1 is authentic and accurately reconstructed from the Notion writeup by Luca Di Domenico.
    The report relies on a third-party writeup for the initial social engineering vector without independent verification.
  • domain assumption The public PHPInfo page at 86.104.74.51 is genuine attacker infrastructure rather than a honeypot or decoy.
    Section 5 draws infrastructure conclusions from this page without considering deception possibilities.
  • domain assumption The eight-minute sandbox execution with 241,000 logged events captures the malware's representative behavior.
    Section 4.6.3 notes that some capabilities, such as process injection and shellcode execution, were not triggered, so the observed behavior is partial.
invented entities (2)
  • Tsunami toolset (Runtime Broker.exe, tsunami payload.exe, Tor-over-IPC C2 channel)
    purpose: Newly reported malware components that disable security, maintain persistence, and communicate over Tor.
    The report provides code snippets and dynamic observations but no hashes or samples, so independent confirmation outside this analysis is not yet possible. This is a reported artifact, not a theoretical postulate.
  • mlip keylogger and clipboard monitor
    purpose: Newly reported Python script that captures keystrokes and clipboard contents containing crypto private keys or mnemonic phrases.
    Reported as identified a few weeks before this campaign; no sample or hash is provided for independent verification.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Lazarus Group Targets Crypto-Wallets and Financial Data while employing new Tradecrafts." pith.science (2026). https://pith.science/paper/IX7CJFV3

@misc{pith2026250521725,
  author       = {Pith},
  title        = {Pith review of: Lazarus Group Targets Crypto-Wallets and Financial Data while employing new Tradecrafts},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/IX7CJFV3}},
  note         = {Machine review of arXiv:2505.21725}
}
read the original abstract

This report presents a comprehensive analysis of a malicious software sample, detailing its architecture, behavioral characteristics, and underlying intent. Through static and dynamic examination, the malware core functionalities, including persistence mechanisms, command-and-control communication, and data exfiltration routines, are identified and its supporting infrastructure is mapped. By correlating observed indicators of compromise with known techniques, tactics, and procedures, this analysis situates the sample within the broader context of contemporary threat campaigns and infers the capabilities and motivations of its likely threat actor. Building on these findings, actionable threat intelligence is provided to support proactive defenses. Threat hunting teams receive precise detection hypotheses for uncovering latent adversarial presence, while monitoring systems can refine alert logic to detect anomalous activity in real time. Finally, the report discusses how this structured intelligence enhances predictive risk assessments, informs vulnerability prioritization, and strengthens organizational resilience against advanced persistent threats. By integrating detailed technical insights with strategic threat landscape mapping, this malware analysis report not only reconstructs past adversary actions but also establishes a robust foundation for anticipating and mitigating future attacks.

Figures

Figures reproduced from arXiv: 2505.21725 by the authors.

Figure 1
Figure 1. Infection Chain Diagram November 26, 2024 [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Attacker trying to engage its victim. The interaction began with what appeared to be a standard recruitment message, con￾taining project details that aligned with the target’s professional expertise and current industry trends. The attacker followed up by requesting that the target download and run a codebase hosted on Bitbucket, presented as part of a skill assessment process. How￾ever, as communication progressed,… view at source ↗
Figure 3
Figure 3. BitBucket malicious repository. Upon examination, the codebase was found to contain obfuscated scripts designed to perform unauthorized actions on the target’s system. This discovery revealed the true November 26, 2024 [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figures from the paper (166 more)
Figure 4
Figure 4. Figure 4: Obfuscated malicious code posed inside the [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]
Figure 5
Figure 5. Figure 5: First Stage The initial JavaScript code is a highly obfuscated script crafted to execute malicious op￾erations, including the deployment of additional payloads, collection of sensitive data and its subsequent exfiltration to a remote server under the attacker’s control…
Figure 6
Figure 6. Figure 6: Variables are renamed to avoid leaking any useful insight. [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]
Figure 7
Figure 7. Figure 7: Code employs lookup-tables for strings to reduce code understandability. [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]
Figure 8
Figure 8. Figure 8: Lookup-table content The script makes extensive use of self-invoking functions and nested function wrap￾pers. These patterns complicate the control flow and make it harder to follow the sequence of execution. By encapsulating code within multiple layers of functions th…
Figure 9
Figure 9. Figure 9: An example of self-invoking and wrapped functions. Another obfuscation technique introduced is the use of the function constructor for dynamic code execution. By constructing new functions at runtime, the script can gen￾erate and execute code that is not visible in its…
Figure 10
Figure 10. Figure 10: Functions are instantiated at runtime to make it harder analyze source code. [PITH_FULL_IMAGE:figures/full_fig_p010_10.png]
Figure 11
Figure 11. Figure 11: Anti-Debugging functionalities November 26, 2024 [PITH_FULL_IMAGE:figures/full_fig_p010_11.png]
Figure 12
Figure 12. Figure 12: Example of Opaque Predicate. Control flow flattening is another technique used to obfuscate the code. By rearrang￾ing the normal execution flow and breaking it into smaller blocks with indirect jumps and calls, the script makes it challenging to follow the logical seq…
Figure 13
Figure 13. Figure 13: Numbers are hex-encoded to add complexity to code analysis. [PITH_FULL_IMAGE:figures/full_fig_p011_13.png]
Figure 14
Figure 14. Figure 14: Usage of confusing naming conventions for script imports. [PITH_FULL_IMAGE:figures/full_fig_p011_14.png]
Figure 15
Figure 15. Figure 15: Refactored main routine of the malicious [PITH_FULL_IMAGE:figures/full_fig_p012_15.png]
Figure 16
Figure 16. Figure 16: Snippet of the refactored capabilities of [PITH_FULL_IMAGE:figures/full_fig_p013_16.png]
Figure 17
Figure 17. Figure 17: Snippet of the refactored capabilities of [PITH_FULL_IMAGE:figures/full_fig_p013_17.png]
Figure 18
Figure 18. Figure 18: Crypto-related browser extensions list. If the collectSolana flag is true, the script also attempts to collect the Solana id.json file from the user’s home directory. This file often contains sensitive wallet information. After this information gathering activity is c…
Figure 19
Figure 19. Figure 19: Malicious function designed to exfiltrate data to remote [PITH_FULL_IMAGE:figures/full_fig_p015_19.png]
Figure 20
Figure 20. Figure 20: Function designed to collect Firefox profiles and extensions. [PITH_FULL_IMAGE:figures/full_fig_p016_20.png]
Figure 21
Figure 21. Figure 21: Function designed to collect the Exodus Cryptowallet information. For Windows systems, the script additionally targets Microsoft Edge by calling col￾lectExtensionData with the appropriate path. This increases the scope of data collec￾tion to include users who primaril…
Figure 22
Figure 22. Figure 22: Function designed to collect the macOS Keychain and browser’s login data. For other platforms, the script calls collectLocalStateAndLoginData for Chrome, Brave, and Opera browsers. This function collects the Local State file, which contains browser settings and encryp…
Figure 23
Figure 23. Figure 23: Function designed to collect credentials from different Browser. [PITH_FULL_IMAGE:figures/full_fig_p019_23.png]
Figure 24
Figure 24. Figure 24: Function related to download and execution of the subsequent infection stages. [PITH_FULL_IMAGE:figures/full_fig_p019_24.png]
Figure 25
Figure 25. Figure 25: Function designed to download and extract a compressed [PITH_FULL_IMAGE:figures/full_fig_p020_25.png]
Figure 26
Figure 26. Figure 26: normalizePath and fileExists functions snippet. These functions ensure that the script can correctly navigate the file system across different operating systems, enhancing its effectiveness and portability. At the end of the script, an interval is set to repeat the ma…
Figure 27
Figure 27. Figure 27: Main function is executed every 5 minutes on the compromised host. [PITH_FULL_IMAGE:figures/full_fig_p021_27.png]
Figure 28
Figure 28. Figure 28: Moving from First to Second Stage. 4.3.1 Code Obfuscation The identified Second-Stage payload is located inside a Python script, stored as %TEMP% \sysinfo script.py and downloaded from hxxp[:]//86.104.74[.]51:1224/client/8/87, car￾rying the initial stage of the Invisi…
Figure 29
Figure 29. Figure 29: Second-Stage payload content. As observed in the preceding image, the malware employs a sophisticated obfuscation strategy designed to hinder analysis. To reveal the underlying payload, analysts must reverse the provided string, decode it using base64, and decompress …
Figure 30
Figure 30. Figure 30: Second-Stage imported modules Identified script defines several variables and sets up the environment. It uses the platform module to determine the operating system type, which is stored in the variable ot. This information is subsequently used to decide how the paylo…
Figure 31
Figure 31. Figure 31: Remote connection configurations The first payload is handled by the function download payload(). It checks if the payload file, named %USERPROFILE%\.n2\pay, already exists in the hidden directory. If it does, it attempts to remove it. Then, the script ensures that th…
Figure 32
Figure 32. Figure 32: Malicious function designed to retrieve and run [PITH_FULL_IMAGE:figures/full_fig_p023_32.png]
Figure 33
Figure 33. Figure 33: An additional Python payload is downloaded from the same [PITH_FULL_IMAGE:figures/full_fig_p024_33.png]
Figure 34
Figure 34. Figure 34: A third Python script is then downloaded and executed. [PITH_FULL_IMAGE:figures/full_fig_p024_34.png]
Figure 35
Figure 35. Figure 35: Moving from Second to Third Stage. As previously noted, this specific infection-stage provides a clear indication of the new tradecrafts being employed by the Lazarus Group in this campaign. Notably, the introduction of a new Python script, mlip, first identified only…
Figure 36
Figure 36. Figure 36: mlip imports and missing libraries installation. This pattern repeats for modules like psutil, win32process, win32gui, win32api, win32con, win32clipboard, requests, and wx. The script uses these modules to interact with Windows system APIs, handle HTTP requests, and i…
Figure 37
Figure 37. Figure 37: Hard-coded very useful information The act win pn() function retrieves information about the active window, such as the process ID, process name, and window caption. These information is used to determine if the user is interacting with one of the targeted browsers […
Figure 38
Figure 38. Figure 38: act win pn() function code snippet The script then defines several utility functions to check the state of control keys and to save logs. Indeed, save log() function is particularly important as it sends the captured data to the remote server using an HTTP POST reques…
Figure 39
Figure 39. Figure 39: C&C Server URL and exfiltration parameters. The OnKeyboardEvent() function is a callback that is triggered on every keyboard event. It checks if the active process is one of the targeted browsers and captures the keystrokes. This function also intercepts clipboard dat…
Figure 40
Figure 40. Figure 40: Callback function to trigger Keylogging activity. In addition to keystroke logging, the script defines the TestFrame class, which inherits from wx.Frame. This class sets up a clipboard viewer that monitors changes to the clipboard. November 26, 2024 [PITH_FULL_IMAGE:…
Figure 41
Figure 41. Figure 41: TestFrame class initialization Within this class, the OnDrawClipboard() method is called whenever the clipboard content changes. It processes the new clipboard data to detect potential private keys or mnemonic phrases [PITH_FULL_IMAGE:figures/full_fig_p028_41.png]
Figure 42
Figure 42. Figure 42: OnDrawClipboard() code snippet The GetTextFromClipboard() method retrieves the clipboard text and checks if it contains sensitive information [PITH_FULL_IMAGE:figures/full_fig_p028_42.png]
Figure 43
Figure 43. Figure 43: Function designed to capture and retrieve sensitive data. [PITH_FULL_IMAGE:figures/full_fig_p028_43.png]
Figure 44
Figure 44. Figure 44: savepvkey() and ismnemonic() implementations Finally, the main loop of the script creates an instance of the TestFrame class and starts the application. This ensures that the clipboard monitoring continues to run as long as the application is active [PITH_FULL_IMAGE:…
Figure 45
Figure 45. Figure 45: Main loop In conclusion, the script operates by covertly logging keystrokes and clipboard contents when the user interacts with specific web browsers. It specifically targets data that resembles cryptocurrency private keys or mnemonic phrases. The captured data is the…
Figure 46
Figure 46. Figure 46: Code shown in Figure [PITH_FULL_IMAGE:figures/full_fig_p030_46.png]
Figure 47
Figure 47. Figure 47: pay script’s imports The script defines sType and gType, constants in this campaign and used to uniquely define it within their various compromising activities. The main function of the script is encapsulated within the run comm() function, which initiates the transmi…
Figure 48
Figure 48. Figure 48: Snippet of run comm() function Within the Trans class, the init method collects system and network information by instantiating the SysInfo class and calling its get info() method. This method ag￾gregates system information such as the operating system, hostname, rele…
Figure 49
Figure 49. Figure 49: Trans class initialization November 26, 2024 [PITH_FULL_IMAGE:figures/full_fig_p031_49.png]
Figure 50
Figure 50. Figure 50: HostInfo class maps host information into a dictionary to be exfiltrated In the HostInfo class, the getID() method generates a unique identifier for the vic￾tim’s machine by hashing the MAC address and username. This UUID is used to uniquely identify the infected syst…
Figure 51
Figure 51. Figure 51: Position class is designed to gather geographical information from victim’s IP. After collecting all the necessary information, the Trans class’s contact server() method sends this data to the attacker’s server using an HTTP POST request [PITH_FULL_IMAGE:figures/full…
Figure 52
Figure 52. Figure 52: Client class setups an interpretative connection to attacker’s servers. The make connection() method attempts to establish a socket connection to the attacker’s server. If successful, it creates a Session object for low-level communication and a Shell object to handle…
Figure 53
Figure 53. Figure 53: Shell class provides the attacker with RAT capabilities. In the Shell class’s constructor, it initializes various attributes and defines a dictionary self.cmds that maps command codes to their corresponding methods. These methods handle different functionalities such …
Figure 54
Figure 54. Figure 54: Function listen recv() code snippet The method receives data from the session, parses it, and dispatches it to the ap￾propriate handler method based on the command code. It uses threading to handle commands concurrently. The shell() method starts the listener thread a…
Figure 55
Figure 55. Figure 55: Shell() translates attacker’s command into ones to be executed on target. Below are some of the handler methods in the Shell class: • ssh obj(self, args): This method allows the attacker to execute arbitrary shell commands on the victim’s machine and returns the outpu…
Figure 56
Figure 56. Figure 56: Function used to download any.py, which gets and runs AnyDesk. An additional essential part of the malware’s operation is its capability to search for and exfiltrate sensitive files from the victim’s system. It defines patterns and exclusion lists to target specific f…
Figure 57
Figure 57. Figure 57: Arrays embedding file’s extensions to be serached on target system. [PITH_FULL_IMAGE:figures/full_fig_p035_57.png]
Figure 58
Figure 58. Figure 58: How files with known extensions are exfiltrated. [PITH_FULL_IMAGE:figures/full_fig_p035_58.png]
Figure 59
Figure 59. Figure 59: run client() deploys keyboard hooking functionality. The hk loop() function sets up the hooks for keyboard and mouse events using pyHook. Within the event handlers, the script captures keystrokes and writes them to a buffer. It also captures clipboard content when the…
Figure 60
Figure 60. Figure 60: Main Hooking routine At the end of the script, the run client() function is called within the main block to start the malware’s execution. Regarding unused code, there are several sections where function calls are commented out, such as in the auto up() function. This…
Figure 61
Figure 61. Figure 61: Crypto-Wallet related patten which have been commented out. Additionally, the write txt() function is defined but does not perform any operation. It may have been intended to log captured keystrokes or clipboard content to a file but remains unused [PITH_FULL_IMAGE:f…
Figure 62
Figure 62. Figure 62: Unused function write txt() In conclusion, the script is a complex piece of malware that performs multiple ma￾licious activities, including system information gathering,data exfiltration, remote com￾mand execution, file searching and uploading, keylogging, clipboard m…
Figure 63
Figure 63. Figure 63: Snippet of the additional Tsunami suite embedded in Bow script. As first, the credential stealing capabilities will be discussed, later also the newly identified functionalities will be analyzed as well. November 26, 2024 [PITH_FULL_IMAGE:figures/full_fig_p037_63.png]
Figure 64
Figure 64. Figure 64: pip imports and management of missing libraries. The script sets up several global variables, including sType, gType, host1 and home, which are used throughout the code for exfiltration and path resolution. It also determines the hostname of the machine and constructs…
Figure 65
Figure 65. Figure 65: Global variables definition and C2 server remote URL construction. The script defines classes representing different browser versions it aims to target. Each class inherits from a base class BrowserVersion and specifies the browser’s base name along with version ident…
Figure 66
Figure 66. Figure 66: Classes defining all the targeted victims’ browsers. [PITH_FULL_IMAGE:figures/full_fig_p039_66.png]
Figure 67
Figure 67. Figure 67: Snippet of the ChromeBase class The retrieve database() method in ChromeBase is responsible for copying the browser’s login data database, decrypting stored passwords, and collecting them for ex￾filtration [PITH_FULL_IMAGE:figures/full_fig_p039_67.png]
Figure 68
Figure 68. Figure 68: retrieve database() targets Chrome locally stored credentials. Similarly, the retrieve web() method extracts credit card information stored by the browser. November 26, 2024 [PITH_FULL_IMAGE:figures/full_fig_p039_68.png]
Figure 69
Figure 69. Figure 69: retrieve web() targets credit cards information. For Windows systems, the Windows class inherits from ChromeBase and implements Windows-specific methods for decrypting passwords. It uses the win32crypt module to interact with Windows Data Protection API (DPAPI) for de…
Figure 70
Figure 70. Figure 70: Windows class initialization and browsers’ paths. For Linux systems, the Linux class implements methods to retrieve the encryption key from the GNOME Keyring using the secretstorage module. November 26, 2024 [PITH_FULL_IMAGE:figures/full_fig_p040_70.png]
Figure 71
Figure 71. Figure 71: Linux class initialization and browsers’ paths. For macOS systems, the Mac class retrieves the encryption key from the Keychain using system commands [PITH_FULL_IMAGE:figures/full_fig_p041_71.png]
Figure 72
Figure 72. Figure 72: Mac class initialization and browsers’ paths. At the end of the script, the main execution flow determines the operating system and initializes the appropriate class to perform the data extraction. It iterates over each available browser, retrieves stored credentials,…
Figure 73
Figure 73. Figure 73: Main routine adapting its behavior within the identified OS. [PITH_FULL_IMAGE:figures/full_fig_p042_73.png]
Figure 74
Figure 74. Figure 74: save() function setups the exfiltration process. Unused code in the script is minimal, with some commented out sections at the end that may have been used for debugging or cleanup purposes [PITH_FULL_IMAGE:figures/full_fig_p042_74.png]
Figure 75
Figure 75. Figure 75: Commented clean-up last lines. This most probably indicates an intention to remove the script after execution, pos￾sibly to cover its tracks, but it is commented out, so it doesn’t execute. In conclusion, this bow script component operates by methodically accessing br…
Figure 76
Figure 76. Figure 76: Bow was hosted, in the past, on this server. November 26, 2024 [PITH_FULL_IMAGE:figures/full_fig_p042_76.png]
Figure 77
Figure 77. Figure 77: Script’s imports The script begins by defining several global variables that are essential to its operation. The DEBUG MODE flag is initialized as False, ensuring that the script suppresses debug output during execution unless explicitly enabled. This configuration em…
Figure 78
Figure 78. Figure 78: Script’s global variables The obfuscate script() function takes the script data and a loop count to determine the level of obfuscation. It replaces a placeholder variable RandVar with a random integer to ensure that the obfuscated script differs on each execution (avo…
Figure 79
Figure 79. Figure 79: 50-iterations obfuscation technique implementation. [PITH_FULL_IMAGE:figures/full_fig_p044_79.png]
Figure 80
Figure 80. Figure 80: Debugging mode The download file() function uses PowerShell to download a file from a given URL to a specified file path [PITH_FULL_IMAGE:figures/full_fig_p045_80.png]
Figure 81
Figure 81. Figure 81: Function designed to download remote utilities. [PITH_FULL_IMAGE:figures/full_fig_p045_81.png]
Figure 82
Figure 82. Figure 82: Function designed to check whether a Python interpreter is available on target [PITH_FULL_IMAGE:figures/full_fig_p045_82.png]
Figure 83
Figure 83. Figure 83: Function designed to runas to install a Python interpreter. By specifying the runas verb, the script prompts the User Account Control (UAC ) dialog to request elevated privileges. The installer is executed with silent installation parameters to avoid user interaction.…
Figure 84
Figure 84. Figure 84: Function designed to run Python installer and prompting for user administra [PITH_FULL_IMAGE:figures/full_fig_p046_84.png]
Figure 85
Figure 85. Figure 85: Script’s main routine In conclusion, the script functions as a dropper that ensures Python is installed on the target Windows system, leveraging administrative privileges if necessary. It then installs a persistent, obfuscated secondary payload in the startup folder t…
Figure 86
Figure 86. Figure 86: Interesting citation available inside Windows Update Script.pyw. The quote, Sometimes you never know the value of a moment until it becomes a memory, is often attributed to Dr. Seuss, although its precise origins are uncertain. The phrase captures a universal truth ab…
Figure 87
Figure 87. Figure 87: Moving from Third to Fourth Stage. 4.5.1 Code Obfuscation In this stage, as yet reported in the previous section, Windows Update Script.pyw was obfuscated with the well-known 50-iterations process. On the other hand, any.py is not ubfuscated at all. 4.5.2 Code Analysi…
Figure 88
Figure 88. Figure 88: any.py imports and global variables The script then defines a function save conf() that reads the contents of a given file and sends it to the attacker’s server. This function checks if the file fn exists. If it does, it reads the file’s contents into buf. If the latt…
Figure 89
Figure 89. Figure 89: Defining AnyDesk path and configuring C2 connection to share its settings. A function get anydesk path() is defined to locate or download AnyDesk if it is not already installed. November 26, 2024 [PITH_FULL_IMAGE:figures/full_fig_p049_89.png]
Figure 90
Figure 90. Figure 90: Funtion designed to establish AnyDesk presence on target system. This function first checks if AnyDesk exists at the default path. If not, it attempts to download AnyDesk from the attacker’s server (host2 + /any). The downloaded exe￾cutable is saved in the user’s home…
Figure 91
Figure 91. Figure 91: Script maps AnyDesk’s configurations related paths. It then defines a PowerShell script as a multi-line string anydesk ps1. November 26, 2024 [PITH_FULL_IMAGE:figures/full_fig_p050_91.png]
Figure 92
Figure 92. Figure 92: anydesk ps1 variable content This script reads the AnyDesk configuration file, replaces certain lines with predefined values (specifically pwd hash, pwd salt, and token salt), and writes the changes back to the file. It then forcefully terminates AnyDesk. The core fun…
Figure 93
Figure 93. Figure 93: Function designed to update AnyDesk configurations. This function first checks if the configuration file at d path exists. It then reads the file to see if it already contains the attacker’s pwd salt. If not, it proceeds to modify the file. It opens the existing confi…
Figure 94
Figure 94. Figure 94: Configurations update and AnyDesk restart. This function kills any running AnyDesk processes and restarts them subsequently. On non-Windows systems, it uses the psutil library to iterate over running processes and terminate them. On Windows, it uses the taskkill comma…
Figure 95
Figure 95. Figure 95: Manipulation of the AnyDesk configuration and settings. Deleting itself is a common tactic in malware to reduce forensic evidence and avoid detection. Regarding unused code, the script includes commented-out print statements and ex￾ception handling that does not repor…
Figure 96
Figure 96. Figure 96: Script’s imports and anti-fingerprinting variable [PITH_FULL_IMAGE:figures/full_fig_p053_96.png]
Figure 97
Figure 97. Figure 97: Global variables embedding additional payloads information and paths. [PITH_FULL_IMAGE:figures/full_fig_p054_97.png]
Figure 98
Figure 98. Figure 98: Code snippet of the embedded TSUNAMI PAYLOAD SCRIPT. Within this embedded script, the add windows defender exception() function attempts to add specific file paths to the Windows Defender Exclusion List by executing PowerShell commands. The create task() function crea…
Figure 99
Figure 99. Figure 99: Function designed to check whether Runtime Broker.exe is in a scheduled task. Then, the script defines functions to decrypt and decode an obfuscated URL from which it downloads an additional malicious payload. These functions perform xor en￾cryption/decryption (key: !…
Figure 100
Figure 100. Figure 100: Functions designed to decrypt the strings embedded in the [PITH_FULL_IMAGE:figures/full_fig_p055_100.png]
Figure 101
Figure 101. Figure 101: download installer url() queries Pastebin profiles and find existing ones [PITH_FULL_IMAGE:figures/full_fig_p056_101.png]
Figure 102
Figure 102. Figure 102: Function designed to download and decode data from [PITH_FULL_IMAGE:figures/full_fig_p056_102.png]
Figure 103
Figure 103. Figure 103: Pastebin profile contacted to retrieve the additional payload [PITH_FULL_IMAGE:figures/full_fig_p057_103.png]
Figure 104
Figure 104. Figure 104: Pastebin file containing the encoded URL for the additional payload location. The decoded string translates to hxxp[:]//23.254.229.101/cat-video and delivers a file named cat video.mp4. This is instead a reversed gzip archive which contains Runtime Broker.exe and get…
Figure 105
Figure 105. Figure 105: download installer() code snippet November 26, 2024 [PITH_FULL_IMAGE:figures/full_fig_p057_105.png]
Figure 106
Figure 106. Figure 106: Function designed to employ runas to install Python as admin. In the main section of the script, the execution flow is as follows [PITH_FULL_IMAGE:figures/full_fig_p058_106.png]
Figure 107
Figure 107. Figure 107: Script’s main routine The script checks if the scheduled task Runtime Broker exists. If it does and the TSUNAMI INSTALLER is not present, it downloads and installs this malicious executable. Otherwise, if it is present, it exits. Then, If a task for the TSUNAMI INSTA…
Figure 108
Figure 108. Figure 108: Developers RickRolling analysts. In conclusion, the script is a sophisticated piece of malware that aims to compromise a Windows system by installing malicious payloads, achieving persistence, and evading security measures. It uses multiple layers of obfuscation and …
Figure 109
Figure 109. Figure 109: Moving from Fourth to Fifth Stage 4.6.1 Code Obfuscation As discussed in the previous section, the TSUNAMI CLIENT script is written to disk with the well-known 50-iterations obfuscation schema. On the other hand, TSUNAMI INSTALLER executable is not a packed executabl…
Figure 110
Figure 110. Figure 110: Script’s imports The script defines global variables that are crucial for its operation. DEBUG MODE flag is set to False, indicating that debug output is suppressed during normal execution. The script retrieves the paths to the roaming and Local AppData directories u…
Figure 111
Figure 111. Figure 111: Global variables declarations November 26, 2024 [PITH_FULL_IMAGE:figures/full_fig_p060_111.png]
Figure 112
Figure 112. Figure 112: Functions designed to check user’s permissions and apply [PITH_FULL_IMAGE:figures/full_fig_p061_112.png]
Figure 113
Figure 113. Figure 113: Function designed to add Runtime Broker.exe as a scheduled task. The script first checks for administrative privileges by calling is admin(). If the script is not running as an administrator, it outputs a warning message (if DEBUG MODE is enabled). However, it procee…
Figure 114
Figure 114. Figure 114: Main routine In conclusion, the script functions as a persistence mechanism for a malicious payload on a Windows system. It attempts to elevate privileges, modifies Windows Defender settings to exclude its files from scanning, and creates a scheduled task that execut…
Figure 115
Figure 115. Figure 115: QueryPerfomanceCounter invoke [PITH_FULL_IMAGE:figures/full_fig_p064_115.png]
Figure 116
Figure 116. Figure 116: DebugBreak invoke Another significant discovery is the use of API calls such as VirtualAlloc and Vir￾tualProtect to allocate and modify memory permissions dynamically. These suggest the malware includes functionality for memory-based payload staging and execution, po…
Figure 117
Figure 117. Figure 117: ShellExecuteW invoke November 26, 2024 [PITH_FULL_IMAGE:figures/full_fig_p064_117.png]
Figure 118
Figure 118. Figure 118: SleepEx invoke Furthermore, the file exhibits the capability to compress and decompress data using Zlib (compress data via Zlib inflate or deflate) and encode/encrypt data using base64 and xor. These functionalities strongly correlate with obfuscation techniques obse…
Figure 119
Figure 119. Figure 119: Set of values possibly associated with xor activities. New insights from the static analysis also highlight capabilities for obtaining sys￾tem locale and geographical information, as seen in the following image. This discovery introduces the possibility that the malw…
Figure 120
Figure 120. Figure 120: GetLocaleInfoEx invoke Further investigation of the malware’s embedded strings has uncovered the presence of debugging information, left behind by the developers. These artifacts provide valuable insights into the attacker’s behavior and offer a deeper understanding …
Figure 121
Figure 121. Figure 121: Debugging strings left behind by malware developers. [PITH_FULL_IMAGE:figures/full_fig_p066_121.png]
Figure 122
Figure 122. Figure 122: Tsunami strings embedded in Runtime Broker.exe. By determining the address range associated with the most noteworthy strings and lo￾cating the specific executable segment containing this memory region, it became possible to isolate and extract the embedded component …
Figure 123
Figure 123. Figure 123: Runtime Broker.dll overview Since the library was written in .NET, it was possible to load it into dnSpy and examine its source code directly. Remarkably, debug information was still intact, and the code appeared completely unobfuscated, with human-readable functions…
Figure 124
Figure 124. Figure 124: Runtime Broker.dll reversed content The Main method initializes the program by invoking Meta.Init, setting its usage type to TsunamiInstaller with a specified version, i.e. 1.0.0, before invoking the Start() method. The inclusion of an infinite loop at the end ensure…
Figure 125
Figure 125. Figure 125: Runtime Broker.dll Main method. At this point, each implemented class and its respective functionalities will be thor￾oughly examined, following a cascading order from the first to the last as they appear in the execution flow of the Main method. This approach ensure…
Figure 126
Figure 126. Figure 126: Overview of Meta class November 26, 2024 [PITH_FULL_IMAGE:figures/full_fig_p070_126.png]
Figure 127
Figure 127. Figure 127: Overview of the DisableWindowsSecurity() method The AntiDefender class represents a set of functions aimed at disabling key Windows security features, specifically Windows Defender and Windows Firewall. The methods operate by adding exceptions to these defenses for s…
Figure 128
Figure 128. Figure 128: Overview of the AntiDefender class Upon further analysis of the AntiDefender class, it becomes evident that it contains a hardcoded list of file paths that are subjected to the whitelisting process. The paths in question include critical system directories and filena…
Figure 129
Figure 129. Figure 129: Hardcoded paths of additional payloads undergoing [PITH_FULL_IMAGE:figures/full_fig_p073_129.png]
Figure 130
Figure 130. Figure 130: Overview of the Shell class November 26, 2024 [PITH_FULL_IMAGE:figures/full_fig_p074_130.png]
Figure 131
Figure 131. Figure 131: Snippet of TorProxy class The CheckForUpdates() method is a robust implementation designed to manage updates for the Tsunami Client application. It combines multiple functionalities to ensure the client executable is current, secure, and operational. The process begi…
Figure 132
Figure 132. Figure 132: Overview of CheckForUpdate() method The susscessive analysis of the ResourceManager component reveals the presence of two notable embedded resources: a tor.exe file and a tsunami payload.exe. While the first file, tor.exe, is actively extracted and utilized by the ma…
Figure 133
Figure 133. Figure 133: tsunami payload.exe availability with no reference to its deployment. The TorServer class provides functionality for establishing and managing communi￾cation with a remote server over the Tor network. It facilitates tasks such as session initialization, environment i…
Figure 134
Figure 134. Figure 134: JSON -based template with acquired information to exfiltrate. November 26, 2024 [PITH_FULL_IMAGE:figures/full_fig_p079_134.png]
Figure 135
Figure 135. Figure 135: API endpoint paths for each single activity the malware takes care of. • hxxp[:]//n34kr3z26f3jzp4ckmwuv5ipqyatumdxhgjgsmucc65jac56khdy5zqd[.]onion/ assets/v2/dotnet6-installer-ur • hxxp[:]//n34kr3z26f3jzp4ckmwuv5ipqyatumdxhgjgsmucc65jac56khdy5zqd[.]onion/ api/v1/disc…
Figure 136
Figure 136. Figure 136: Discord and Browser paths are not read by any function. By proceeding with the code analysis, it is possible to focus on the ComputerInfo class. The latter is designed to gather detailed system information, leveraging both managed .NET functionality and native Window…
Figure 137
Figure 137. Figure 137: Snippet of the ComputerInfo class The ExecuteTsunamiClient() method manages the execution of the Tsunami Client, with a focus on ensuring the necessary runtime environment, such as .NET 6, is installed and operational. It begins by verifying if the .NET 6 framework i…
Figure 138
Figure 138. Figure 138: Overview of the ExecuteTsunamiClient() The TelemetryUploader class appears to be designed for aggregating and transmitting application logs to a remote server under the guise of legitimate telemetry functionality. The SendApplicationLogs() method processes runtime lo…
Figure 139
Figure 139. Figure 139: Overview of the TelemetryUploader class The UserInteractions class is a utility designed to monitor and analyze user activity and system interaction states. It relies on Windows API calls to retrieve idle time, detect fullscreen applications, and assess the user’s la…
Figure 140
Figure 140. Figure 140: Overview of the unused UsersInteractions class The CaesersCipher class implements a classical Caesar cipher encryption and decryp￾tion algorithm, providing basic functionality for shifting letters in a string by a specified number of steps. Despite its simplicity and…
Figure 141
Figure 141. Figure 141: Overview of the unused CaesarsCipher class Dynamic Analysis The execution of Runtime Broker.exe shows, as first, the executable being accessed from the %APPDATA%\Roaming\Microsoft \Windows directory. This unconventional execution path immediately raises suspicions, a…
Figure 142
Figure 142. Figure 142: Runtime Broker.exe loading system libraries. November 26, 2024 [PITH_FULL_IMAGE:figures/full_fig_p087_142.png]
Figure 143
Figure 143. Figure 143: Runtime Broker.exe querying interesting registry keys. Additional file operations involve interactions with apphelp.dll, a library often associ￾ated with compatibility and application support in Windows. This may indicate attempts to exploit or modify application com…
Figure 144
Figure 144. Figure 144: Runtime Broker.exe interacting with apphelp.dll. Then, there are several attempts to access specific registry keys under HKLM\Software \Policies\Microsoft\Windows\Display and HKLM\SOFTWARE\Microsoft\Windows NT \CurrentVersion. These actions frequently result in a NAM…
Figure 145
Figure 145. Figure 145: Executable querying extensively the HKLM hive. Later, activities shift toward file handling and memory management. Operations like CreateFileMapping and FASTIO RELEASE FOR SECTION SYNCHRONIZATION ap￾pear, signaling interaction with memory-mapped files. These are comm…
Figure 146
Figure 146. Figure 146: Executable interacting with rpcss.dll. The process queries and opens multiple registry keys under paths such as HKLM \Software\Microsoft\Windows\CurrentVersion and HKLM\System\CurrentControlSet. The successful results for these actions indicate that the queried keys …
Figure 147
Figure 147. Figure 147: Executable continues to map the HKLM hive looking for keys of interest. Registry-related events dominate this range, with key activities including RegQueryKey, RegOpenKey, and RegCloseKey. The keys being accessed, such as those under Con￾trol\Hvsi and Nls\Sort, sugge…
Figure 148
Figure 148. Figure 148: Executable interactions with Control\Hvsi and Nls\Sort. The occasional NAME NOT FOUND details for specific queries, such as in the Reg￾QueryValue operation under Control\Hvsi\IsHvsiContainer, indicate that some queried values are absent, perhaps revealing conditional…
Figure 149
Figure 149. Figure 149: Runtime Broker.exe tries to identify the presence of HVSI container. There is also evidence of deeper system exploration, such as the retrieval of data related to kernel32.dll. This could imply attempts to verify core system library availabil￾November 26, 2024 [PITH…
Figure 150
Figure 150. Figure 150: Runtime Broker.exe tries to map PowerShell.exe instances. There are also interactions with files related to system patching and PowerShell, such as sysmain.sdb in the C:\Windows\apppatch directory and powershell.exe in the C:\Windows\System32\WindowsPowerShell\v1.0 p…
Figure 151
Figure 151. Figure 151: Additional system queries made by Runtime Broker.exe. As depicted in the accompanying image, the establishment of these exclusions occurs in two distinct phases, executed by separate components. Initially, upon the execution of Runtime Broker.exe, all six new firewal…
Figure 152
Figure 152. Figure 152: Windows Firewall exclusions A similar fail-safe rationale is evident in the implementation of AV exclusions. Prior to the active execution of Runtime Broker.exe, the TSUNAMI PAYLOAD script was responsible for modifying Defender’s policies and registering Runtime Brok…
Figure 153
Figure 153. Figure 153: Defender’s exclusions Furthermore, it is also interesting how the TSUNAMI CLIENT refers to the XM￾Rig Miner path as %LOCALAPPDATA%\Microsoft\Windows\Applications\msedge.exe, at the same time, this path is not embedded inside the Runtime Broker.exe code, which instead…
Figure 154
Figure 154. Figure 154: Malware execution stops around 17:49:50 to the restart at 17:54:20. [PITH_FULL_IMAGE:figures/full_fig_p093_154.png]
Figure 155
Figure 155. Figure 155: Runtime Broker.exe drops an embedded malicious executable in %TEMP%\Runtime Broker.exe. Once deployed, this additional payload is also executed to achieve a TOR connections towards remote networks [PITH_FULL_IMAGE:figures/full_fig_p093_155.png]
Figure 156
Figure 156. Figure 156: %TEMP%\Runtime Broker.exe is executed From the initiation of the execution until it was terminated, spanning a total duration of eight minutes and resulting in the logging of over 241,000 events, the initial Runtime Broker.exe process actively transmitted data from t…
Figure 157
Figure 157. Figure 157: Runtime Broker.exe sends acquired data to the local TOR SocksPort. The behavior involving the parent process sending data through a child process that runs Tor represents an interesting and deliberate design choice to use Tor as a local proxy to exchange data between…
Figure 158
Figure 158. Figure 158: TOR Client connecting towards TOR Network. By trying to load the executable inside ILSpy, it is also possible to gather the presence of the DotNetTor DLL (v.2.3.3.0) as an additional reference to the discussion provided above [PITH_FULL_IMAGE:figures/full_fig_p096_1…
Figure 159
Figure 159. Figure 159: Runtime Broker.exe implements DotNetTor library. In conclusion, the observed execution demonstrates the malware’s primary objective: to comprehensively map the victim’s system asset, exfiltrate valuable information, and deploy additional payloads. However, it is evid…
Figure 160
Figure 160. Figure 160: Moving from Fifth-Stage to Sixth-Stage. 4.7.1 Code Obfuscation With respect to different six executables identified as possible additional threats, only one of them was actively deployed on the analyzed system, %TEMP%\RuntimeBroker.exe, tor.exe and is not a packed ex…
Figure 161
Figure 161. Figure 161: Overview of the TSUNAMI PAYLOAD embedded .NET DLL The code demonstrates clear intentions to disable system security features, establish persistence through a scheduled task, initiate Tor-based communication, and send teleme￾try data to a remote server. The Main metho…
Figure 162
Figure 162. Figure 162: Tsunami payload.dll Main method In summary, the tsunami payload.dll performs a narrowed subset of the actions seen in its preceding stage, while embedding a significant portion of the same source code. Despite this overlap, a few critical differences are notable. One…
Figure 163
Figure 163. Figure 163: Overview of the PHPInfo() available on attacker’s main Webserver. Further examination reveals that key configurations, such as the enabled allow url fopen directive and permissive upload and execution parameters (upload max filesize=1024M ), could facilitate maliciou…
Figure 164
Figure 164. Figure 164: Some additional parameters November 26, 2024 [PITH_FULL_IMAGE:figures/full_fig_p101_164.png]
Figure 165
Figure 165. Figure 165: Information about the underlying Windows Server system. [PITH_FULL_IMAGE:figures/full_fig_p102_165.png]
Figure 166
Figure 166. Figure 166: Server’s Software lists The server IP address is confirmed by the SERVER NAME, SERVER ADDR, and HTTP HOST variables. The SERVER SIGNATURE reveals the software stack being used, which includes Apache and PHP, while running on a Windows (Win64 ) environ￾ment. This stac…
Figure 167
Figure 167. Figure 167: Server’s Environmental variables The CLIENTNAME, SESSIONNAME, and LOGONSERVER values collectively con￾firm that the attacker has direct, manual access to the server, which might indicate an interest in maintaining control of the asset beyond automated scripts. This m…
Figure 168
Figure 168. Figure 168: Server’s remote RDP connection details and Temp folders paths. In conclusion, the asset under analysis is a Windows server, powerful and versatile, configured for both web hosting and script execution, with active RDP-based control by an attacker using administrative…
Figure 169
Figure 169. Figure 169: Overview of the AlienVault OTX pulse November 26, 2024 [PITH_FULL_IMAGE:figures/full_fig_p107_169.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

3 extracted references · 3 canonical work pages

  1. [1]

    ca- tions that require exceptions in both Windows Defender and the Firewall. These paths include various directories, such as temporary locations, application folders , and known Windows directories, where components like Runtime Broker.exe, System Runtime Monitor.exe, and msedge.exe are stored. By using the KnownFolder class to retrieve specific system p...

    work page 2024

  2. [32]

    The pro- cessor is identified as Intel64 Family 6 Model 79 Stepping 1, GenuineIntel , highlighting that this asset has substantial computational resources, possibly indicating a server-grade machine or a high-end workstation. This level of computing power suggests that the sys- tem is capable of supporting demanding operations, such as encryption, network...

    work page 2024

  3. [80]

    Runtime Broker

    implies that the server may not enforce secure ( HTTPS ) communications, leaving it potentially vulnerable to Man-in-the-Middle (MITM ) attacks. The presence of a web-based dashboard (HTTPREFERER set to hxxp[:]//86.104.74[.] 51/dashboard/) implies that the server is being used to host a control panel, which may be central to managing the infrastructure or...

    work page 2024

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.