Daily Summary
QuasarRAT activity rose to 9 new samples on 2026-10-11, an 85% increase over the 7-day average of 5. The count is small in absolute terms, but the jump is meaningful relative to the low baseline the family has held over the past week. No new C2 servers were registered, suggesting the additional samples are reusing existing infrastructure rather than expanding it.
New Samples Detected
The file type split is heavily skewed toward executables, with 8 of 9 samples arriving as .exe and a single .js file. That lone script is the outlier worth watching: QuasarRAT is a .NET binary and does not ship as JavaScript natively, so the .js sample is almost certainly a dropper or loader stage that fetches and executes the payload at runtime. This pattern is consistent with a staged delivery chain rather than a direct executable download, and it may indicate the operator is testing a lighter initial-access wrapper to slip past gateways that only quarantine known QuasarRAT binaries.
IOC Highlights
All 9 new IOCs are first-seen today, with zero reuse from previously tracked hashes. Since no new C2 servers appeared alongside them, the fresh IOCs are likely payload hashes, file paths, or mutexes generated from rebuilt binaries rather than infrastructure indicators. This separation matters during triage: blocking the hashes will not disrupt the operator’s command channels, so detection should lean on behavioral signatures (process injection, persistence via registry Run keys, outbound .NET HTTP callbacks) rather than static blocklists alone.
Security Analysis
The combination of rising sample count with flat C2 infrastructure points to a rebuild-and-reskin cycle rather than a new campaign: the same operator is likely recompiling QuasarRAT with altered hashes to reset static-detection clocks, a tactic seen in commodity RAT distribution where builders regenerate unique binaries per victim or per wave. This contrasts with the clustered C2 patterns typical of larger QuasarRAT campaigns, where new samples come with new domains. Because the single .js file breaks from the otherwise uniform .exe set, treat it as a possible early probe of a new delivery path rather than noise. Defensive recommendation: prioritize detecting the execution chain over the binary itself, specifically monitoring for script interpreters (wscript.exe, cscript.exe) spawning .NET assemblies or unsigned executables, and alert on child processes of Office or browser parents, since this catches both the staged loader and any future recompiled payloads regardless of hash.