{
	"id": "6b45b1a7-0af6-47d2-bece-896e1209f969",
	"created_at": "2026-04-06T00:19:22.900308Z",
	"updated_at": "2026-04-10T03:21:57.935085Z",
	"deleted_at": null,
	"sha1_hash": "7c1fc4a6a8eef71e017404d1b7348e4af04a9972",
	"title": "Detecting evolving threats: NetSupport RAT campaign",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 660875,
	"plain_text": "Detecting evolving threats: NetSupport RAT campaign\r\nBy Christopher Morrison\r\nPublished: 2024-08-01 · Archived: 2026-04-05 16:58:44 UTC\r\nThursday, August 1, 2024 06:00\r\nCisco Talos is actively tracking multiple malware campaigns that utilize NetSupport RAT for persistent\r\ninfections. \r\nThese campaigns evade detection through obfuscation and updates. \r\nSnort can provide a strong defense before this malware reaches endpoints. \r\nIn this first Deep Dive with NTDR, we explore how defenders can leverage Snort for the detection of\r\nevasive malware threats. \r\nIn November 2023, security vendors identified a new NetSupport RAT campaign that used fake browser updates\r\nfrom compromised and malicious websites to trick users into downloading a stager that downloads and invokes\r\nPowerShell commands to install the NetSupport manager agent onto the victim’s machine and establish\r\npersistence. \r\nIn January 2024, security researchers published another analysis of the same campaign, although with some\r\ndifferences in the initial JavaScript payload, which demonstrates a threat actor re-focusing on the obfuscation of\r\nthe initial stager. There are also modifications observed in the agent installation including new paths for the\r\nrandomized installation. \r\nSo, Cisco Talos followed suit with our own in-depth analysis. We identified multiple obfuscation and evasion\r\ntechniques being used by the campaign and created appropriate detection to keep users protected. By identifying\r\nhttps://blog.talosintelligence.com/detecting-evolving-threats-netsupport-rat/\r\nPage 1 of 9\n\nspecific weaknesses in the campaign’s obfuscation techniques and identifying indicators of compromise (IOCs),\r\nwe can create highly accurate detection of this campaign. Talos is also in a unique position of having primarily\r\nopen-source detection tools such as Snort and ClamAV. To highlight these capabilities, we will provide a detailed\r\nexplanation of our detection methodology. \r\nCampaign history \r\nNetSupport Manager has been commercially available for remote device administration since 1989. Like many\r\ntools in the IT remote support industry, NetSupport Manager has been weaponized by threat actors who either\r\ncannot or do not wish to develop their own RAT. Adversaries first started using NetSuport for malicious purposes\r\nin 2017, and at this point, most security vendors widely recognize this software as a RAT. The 2020s' shift to\r\nremote work for many office workers marked an increased use of NetSupport RAT in more phishing and drive-by\r\ndownload campaigns, as well as being used alongside other loaders. This campaign is the most notable use of\r\nNetSupport RAT in recent years, with hundreds of known stager variants across dozens of domains used in a\r\nlarge-scale malicious advertising campaign. \r\nComponent summary \r\nComponents in VirusTotal graph. \r\n1. Stage 1 is a JavaScript file that is downloaded from one of several malicious advertisements or\r\ncompromised websites. It’s an obfuscated downloader, keeping a Stage 2 JavaScript and PowerShell\r\npayload in memory, which is the actual meat of the dropper. Stage 1 is obfuscated and embedded within\r\notherwise benign JavaScript libraries. \r\n2. In Stage 2, a PowerShell script is run via JavaScript. Both are obfuscated, and the PowerShell is embedded\r\nin the JavaScript, and the JavaScript is embedded within large comment blocks of random ASCII hex. The\r\nPowerShell makes another HTTP GET to retrieve the base64-encoded ZIP. On receipt, the PowerShell\r\nextracts the payload into a semi-random path, starts execution, and then establishes basic registry\r\npersistence. \r\nhttps://blog.talosintelligence.com/detecting-evolving-threats-netsupport-rat/\r\nPage 2 of 9\n\n3. The end payload is a completely portable install of the commercial NetSupport Manager RAT utility. Some\r\nof the installs come with additional scripts or slight filename changes to avoid more narrow detection. \r\nStage 1: JavaScript stager \r\nFrom 3b587d0c311e8ebc3bb104d564235c41ef8e64592c7419f17f48e0cee9ebc878. \r\nThe screenshot above shows the normalized inner payload for an older version of the JavaScript Stage 1. In this\r\nolder sample, the actual malicious code is embedded within an otherwise benign JavaScript library. Several\r\nlibraries are used, including jQuery, moment.js and SheetJS. However, this stage's actual malicious payload is\r\nbarely obfuscated. The next stage download URL is in plain text. The call to “activeXObject” to create the HTTP\r\nconnection is in plain text. And similarly, the eval call is in plain text. \r\nFrom 01d867d552a06bd778c812810a476441681c4bebabf967e80f8024b3856cb03e \r\nHere, we have the normalized content of a very recent (first seen 2024.03.09) sample of the stager from the same\r\ncampaign. Similarly to the older version, the malicious payload is wrapped in an otherwise benign library.\r\nImproving over the previous versions, the malicious payload within is further obfuscated with the open-source\r\nhttps://blog.talosintelligence.com/detecting-evolving-threats-netsupport-rat/\r\nPage 3 of 9\n\ntool javascript-obfuscator. This results in the removal of the plaintext “activeXObject” and “eval,” however, the\r\noutput pattern of JavaScript-obfuscator is highly identifiable, as every variable and function name is a random\r\nhexadecimal value prefixed by an underscore. \r\nDeobfuscated 01d867d552a06bd778c812810a476441681c4bebabf967e80f8024b3856cb03e \r\nThe old and new samples shared two major features: All the obfuscation is pre-computed and not done on a per-download basis. This is observable through the fact that so many of the stages can be identified with common\r\nentry point functions after having been obfuscated with javascript-obfuscator. Also, the pre-obfuscated stagers are\r\nreused by stamping them with a new random download URL. This URL then ends up being in plain text as well so\r\nfrom identifying the highly unique function names from one stager, we can find many more and then\r\nautomatically extract the download URLs from them statically, which is much faster than throwing them all in\r\nanalysis sandboxes.  \r\nFast pattern-only rule for detection. \r\nStage 1 detection \r\nFrom a detection standpoint, we can use Snort to leverage a fast_pattern-only file rule. This simple rule will only\r\ndetect the given cluster of stagers being downloaded. However, since this is a fast_pattern-only rule on highly\r\nunique text, we can put it in the more general Snort policy configurations since there is little overhead to running\r\nthis rule. Additionally, the Snort 3 file rule will do all the abstraction from other protocols that can carry files, such\r\nas FTP and SMTP, letting us cast our coverage net over a broader attack surface in case this file is being\r\ntransmitted through more ways than just the known malicious advertisement. \r\nStage 2: JavaScript \u0026 PowerShell dropper \r\nThe second stage of the campaign is an in-memory payload downloaded by the on-disk JavaScript. This stage\r\nconsists of a JavaScript function that then calls PowerShell. \r\nhttps://blog.talosintelligence.com/detecting-evolving-threats-netsupport-rat/\r\nPage 4 of 9\n\nFrom 6f3681cd91f7a19c1cf2699e1f9f7b550dfe46841ab5171124e79979fae5424a \r\n The JavaScript content is padded on either side by large, repeating, random comment blocks. The actual\r\nJavaScript is quite simple, a slightly obfuscated call to ActiveXObject(“WScript.Shell”), which allows the\r\nPowerShell command-line to be run. \r\nDeobfuscated from 6f3681cd91f7a19c1cf2699e1f9f7b550dfe46841ab5171124e79979fae5424a \r\nhttps://blog.talosintelligence.com/detecting-evolving-threats-netsupport-rat/\r\nPage 5 of 9\n\nThe PowerShell invocation is where most of the dropper’s work happens. PowerShell is run with the command\r\nline flags “-Ex Bypass” which sets the execution policy to “Bypass”, enabling unsigned execution, “-NoP” which\r\nis short for “-NoPolicy” and avoids the current user’s startup script, and “-C” which is short for “-command” and\r\nwill run the following command line string as a PowerShell script. The commands themselves are a\r\nstraightforward download of the next stage, which is a base64-encoded ZIP file that contains a portable\r\ninstallation of NetSupport Manager Agent. After downloading the payload, it is base64-decoded, written to disk,\r\nand then extracted to the target install folder. A check is run to make sure “client32.exe,” the main executable of\r\nthe agent, exists in the output directory and then this file is run. Finally, a registry entry is made to establish user-level persistence of the agent on login. \r\nInterestingly, this stage is not obfuscated with the same techniques as the Stage 1 file. The PowerShell file is only\r\nslightly obfuscated through random variable names and string concatenations, and the JavaScript obfuscation uses\r\nthe same techniques in addition to the mentioned large random comment blocks. Because this obfuscation is so\r\nlimited, we can rely on static signatures in this case. If future versions of this stager are further obfuscated, using\r\nnormalized content buffers in Snort such as js_data can provide a consistent view into the payload. However, this\r\npayload has remained largely unchanged besides the payload URLs from November 2023 to March 2024. \r\nStage 2 detection \r\nFor Snort detection, we can use a simple series of content that matches the content of the PowerShell script. The\r\nunobfuscated registry key for persistence combined with the PowerShell flags makes a great rule for potential\r\nmalware dropper detection. We can narrow this even further with the inclusion of the client32.exe filename so that\r\nwe know we are only alerting on this campaign and similar uses of NetSupport RAT. \r\nAn additional trick would be the use of an HTTP service rule. In Snort 3, the service inspector can identify known\r\nservices regardless of the port they are on, in contrast to Snort 2 where you will need to define HTTP_PORTS\r\nahead of time. Regardless of what port the attacker is hosting the HTTP payload on, our rule can detect the\r\nmalicious content. \r\nThis Snort rule identifies and prevents the current iteration of dropper payloads. A more holistic approach to\r\ndefense would also include behavioral detection. Since we can observe this dropper’s behavior regardless of any\r\ntext obfuscation, we will effectively forbid this technique on any protected endpoint and force the threat actor to\r\nchange tactics. \r\nhttps://blog.talosintelligence.com/detecting-evolving-threats-netsupport-rat/\r\nPage 6 of 9\n\nExample Sigma detection. \r\n The Sigma behavioral rule language can encapsulate this detection quite well. This rule can detect most installs\r\nbut will fail to identify obfuscations through renames or different registry keys. \r\nObfuscated NetSupport manager download \r\nRetreading a little bit, the PowerShell invocation downloads a base64-encoded ZIP file of an entire installation of\r\nNetSupport Manager agent. For NetSupport Manager and most other legitimate software packages, this is a highly\r\nunusual way for the package to be distributed. Most applications are installed via an MSI package or an EXE\r\ninstaller that downloads the full application without obfuscation. The client binaries are not obfuscated by the\r\nthreat actor since obfuscating an existing compiled binary is more challenging than obfuscating the source code\r\nscripts identified in stage 1 and stage 2 files. Because of this, the unique DLLs that encompass most of the\r\nNetSupport Manager Client’s actual logic are not renamed. \r\nIt might seem we will have to stream decode the base64 content and unzip it in memory to scan for malicious file\r\ncontents; we can exploit two specific features of the ZIP in base64 format. The highly unique DLL names will all\r\nbe close together in the ZIP archive central directory, the structure that holds the information on what files are in\r\nthe archive. Second, base64 is not a random encoding, and we can pre-compute all three possible base64-encoded\r\nstrings that represent any one given input. CyberChef has an excellent demonstration of how this works. This\r\nmethod involves the possible two-bit alignment positions within the six-bit encoding size of a given base64\r\ncharacter. Putting all this together means that we can pre-compute all the combinations of the base64-encoded\r\nDLL names as high-speed rules that are only looking for static content matches.  \r\nhttps://blog.talosintelligence.com/detecting-evolving-threats-netsupport-rat/\r\nPage 7 of 9\n\nBase64 pre-encoded matches in a Snort rule.\r\nThe threat actors using NetSupport RAT in this campaign are typically looking for the fastest way to get a RAT\r\nagent into deployment. The threat actors who use NetSupport Manager are not putting a strong amount of effort\r\ninto obfuscation of droppers, let alone the agents, so this is an effective rule for their non-standard download\r\npaths.  \r\nAdditional Snort detections \r\nTalos has existing Snort coverage for NetSupport Manager Agent’s network activity leveraging SID 44678, which\r\nwas created back in 2017. We also expanded this coverage in 2020, with the creation of SIDs 53539 - 53544 as the\r\nusage by malicious actors increased. For the latest campaign, we increased our coverage through a Snort feature\r\nthat was not available before. File Rules are a feature only available in Snort 3 that allows the abstraction of file\r\ncontents from the protocols that carry them, allowing us to write wider-reaching signatures. \r\nResource Information from client32.exe detailing the NetSupport Manager product. \r\nAs the NetSupport RAT files are not typically obfuscated by threat actors and it is a legitimate commercial product\r\nwith many specialized features, there are many opportunities to create detection against the files. For example, in\r\nboth the EXE and DLLs, the full manufacturer and product information for NetSupport Manager Client is\r\ndetailed. \r\nhttps://blog.talosintelligence.com/detecting-evolving-threats-netsupport-rat/\r\nPage 8 of 9\n\nAs other legitimate software binaries are unlikely to include the full metadata for NetSupport Manager, this gives\r\nus a great signature to work with that lets us cleanly identify the binaries without any heavy reverse engineering\r\nneeded. Although Snort does not have a modifier for Unicode strings, Unicode text byte strings can be leveraged\r\nfor detection. Once again, we can use the “file” rule target to throw our detection net over a much larger surface\r\nthan just HTTP downloads. Other campaigns using NetSupport Manager RAT will be observable from this rule\r\nthrough Snort’s ability to inspect file streams from multiple protocols. \r\nAlthough NetSupport RAT continues to be used by malicious campaigns, its widespread use hinders those threat\r\nactors who are not willing to dedicate the resources to develop their own tools or more evasive techniques. And\r\nsince this campaign is still active and updated, we may still observe these techniques being developed and\r\ndeployed by this threat actor. For now, this gives us an example of when a threat is persistent but not advanced. \r\nIndicators of Compromise \r\nIndicators of Compromise associated with this threat can be found here.\r\nSource: https://blog.talosintelligence.com/detecting-evolving-threats-netsupport-rat/\r\nhttps://blog.talosintelligence.com/detecting-evolving-threats-netsupport-rat/\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA"
	],
	"references": [
		"https://blog.talosintelligence.com/detecting-evolving-threats-netsupport-rat/"
	],
	"report_names": [
		"detecting-evolving-threats-netsupport-rat"
	],
	"threat_actors": [],
	"ts_created_at": 1775434762,
	"ts_updated_at": 1775791317,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/7c1fc4a6a8eef71e017404d1b7348e4af04a9972.pdf",
		"text": "https://archive.orkl.eu/7c1fc4a6a8eef71e017404d1b7348e4af04a9972.txt",
		"img": "https://archive.orkl.eu/7c1fc4a6a8eef71e017404d1b7348e4af04a9972.jpg"
	}
}