Inside a Pre-Deployment Syntrix Campaign

In late April 2026, FileScan.io telemetry surfaced a batch script that 21 commercial AV engines had collectively ignored. A closer look revealed something more interesting than a missed detection: a complete four-stage malware delivery chain for a commercial RAT branded Syntrix Client v2.4.1, and its C2 address was still set to 127.0.0.1:4782. The operator had not yet replaced the loopback address with production infrastructure. We had caught the build before it was deployed.

You can find the full FileScan.io report here.

Sample Overview

Syntrix is a commercially advertised remote access trojan based on the open-source Quasar v1.4.x codebase, marketed with claims of HVNC capability, FUD BAT delivery, kernel-mode rootkit functionality, and stealth persistence. The sample we analysed, syn.bat (SHA-256: 62c30a676aaf765f9913ec9ad485fede0a60e1fe4df9947a3d9f37ae990280b5), is the first stage of that delivery chain. It weighs 9.5 MB and, at the time of submission, was clean across all 21 AV engines that scanned it. FileScan detected it as malicious and classified it with the zero-day tag, meaning no prior match existed in our corpus.

What makes this sample worth documenting is not the RAT itself, Quasar forks are common, but the delivery machinery around it, and what the recovered configuration reveals about when we caught it.

A Four-Stage Delivery Chain

The loader is built in layers. Each stage clears a specific defensive hurdle before handing off to the next; the final RAT only loads once every obstacle has been dealt with.

Stage 1 - BAT Dropper. syn.bat opens by attempting to kill Avast with taskkill /f /im AvastUI.exe. It then uses heavily obfuscated PowerShell, backtick-mangled commands, character-array string construction, and a WindowTitle-based covert channel, to decrypt an AES-256-CBC, GZIP-compressed .NET assembly and load it entirely in memory via Assembly.Load. No Stage 2 file ever touches disk.

Stage 2 - Hardware-Breakpoint AMSI Bypass. The in-memory assembly (OdaDdayDFc, 7,168 bytes) neutralises AMSI without modifying amsi.dll bytes. It resolves AmsiScanBuffer by name, writes the address into debug register DR0 via SetThreadContext, then installs a vectored exception handler that intercepts the resulting SINGLE_STEP exception and forces AMSI_RESULT_CLEAN. This hardware-breakpoint approach bypasses amsi.dll memory-integrity checks entirely, relocating the detection surface to debug-register writes in non-debugger contexts.

Stage 3 - UAC Bypass and ETW Patching. The stager (iehxugTGHN) creates a trailing-space clone of C:\Windows\System32 (a Mock Trusted Directory) drops a malicious version.dll alongside a copy of msconfig.exe in that path, and exploits DLL search-order to execute in an elevated context. The full elevated command is passed through the environment variable phantombp: Stage 3 writes the command into it; version.dll’s DllMain expands and executes it. Once elevated, Stage 3 patches ntdll!EtwEventWrite with a single 0xC3 RET byte, killing ETW telemetry before the final payload loads.

Stage 4 - Syntrix RAT. A 3.2 MB ConfuserEx-obfuscated .NET executable, Syntrix Client v2.4.1, connected to 127.0.0.1:4782.

What FileScan Detected

The hashes seeing in the screenshot below represent the files as FileScan extracted them (either as encrypted AES blobs or as compressed resources) before decryption and decompression. The clean stage hashes in the IOC table at the end of the blogpost were obtained through manual unpacking and will differ accordingly.

Emulation caught the in-memory load and captured the AES key live. FileScan detected a Base64 decoding in PowerShell, observed AES decryption in progress, logging the session key directly: 6VPWdgRKEDDQ/kwHLnwp9KI3BEy3WPCFvCJdsSbTvnQ=, and detected reflective .NET assembly loading (Stage 2 being pulled into memory without a disk write).

Static string analysis flagged the UAC bypass before emulation. FileScan identified msconfig.exe as a living-off-the-land utility artifact (the Mock Trusted Directory mechanism was detectable from binary strings alone), found base64-encoded PE files, and caught the AV kill command targeting AvastUI.exe. Anti-VM logic was also detected via a YARA match, confirming the operator expected sandbox environments and tried to account for them.

Inside the Syntrix Payload

The Stage 4 payload is a Quasar v1.4.x fork with a modest set of additions on top. Preserved verbatim from Quasar: the Quasar.Common.Messages namespace, the Quasar Client Startup scheduled task name, the protobuf-net C2 message framing, and TCP port 4782. The operator changed very little of the underlying RAT.

What Syntrix does add beyond the stock Quasar codebase: Yandex browser credential theft via the Ya Passman Data profile database (absent from stock Quasar), Chrome AES-GCM credential decryption via an embedded BouncyCastle library (filling a gap in .NET Framework 4.x’s native cryptography), a geolocation lookup to ipwho.is before C2 contact, WMI-based AV and firewall product enumeration, and an operator TAG config field set to Office04 in this build, likely a campaign or target group label.

What is explicitly absent from this build despite appearing in Syntrix promotional material: HVNC, kernel-mode rootkit functionality, and audio capture. Binary analysis found no corresponding API strings, driver loading code, or hidden desktop implementation. Advertised capabilities are not the same as confirmed ones.

A Build That Was Not Ready

Three independent findings in the decrypted configuration point to the same conclusion.

The C2 host is 127.0.0.1:4782, a loopback, pointing back at the operator’s own machine. Both the INSTALL and STARTUP persistence flags are false, meaning the RAT would not have achieved persistence even if it had run on a target system. The config version field reads 2.4.2 while the PE assembly version is 2.4.1.0, suggesting the operator embedded a newer configuration into an older compiled client, an inconsistency consistent with an active build-and-test cycle.

FileScan’s zero-day tag arrives at the same conclusion from a different direction: no prior sample in our corpus matched this build.

Detection and Hunting

Three pivots cover the most ground with the least noise.

Host-based: the phantombp behavioural chain. The sequence of a trailing-space C:\Windows \System32 directory being created, version.dll dropped under that path, msconfig.exe launched from the same mock directory, and the environment variable phantombp set immediately before, is an extremely specific combination. It maps to Sysmon EventIDs 1 (process creation), 11 (file creation), and 13 (registry). A Sigma rule covering this chain fires on this loader regardless of what the final payload is.

Static binary: Syntrix branding alongside the Quasar namespace. Searching for "Syntrix Client" combined with "Quasar.Common.Messages" on any content-search capable platform returns Syntrix-family builds with near-zero false positives. The Quasar namespace survives ConfuserEx obfuscation because the operator didn’t use the Method reference hiding and Symbol renaming protection layers.

Network: TCP/4782 and .NET SslStream process anomaly. Port 4782 is Quasar’s default C2 port. A non-browser .NET process initiating outbound TLS to this port with a JA4 fingerprint consistent with SslStream rather than a browser profile is a strong Quasar-family candidate. Correlate with the Quasar Client Startup scheduled task on the same host and confidence is high.

Indicators of Compromise

File hashes

Component	SHA-256
Stage 1 - syn.bat	62c30a676aaf765f9913ec9ad485fede0a60e1fe4df9947a3d9f37ae990280b5
Stage 3 - version.dll	6de1117c5407b0e061856351da89328bf6ef3f09ca59633547b8ea095f36625f
Stage 4 - Syntrix RAT	e6d95a868b0bf63b3da5428412fc578d037a2dded9fcc5093d667e75201f44da

Network and host artefacts

Indicator	Value
C2 port (Quasar default)	TCP/4782
Operator tag (this build)	Office04
Startup persistence key	Quasar Client Startup