Inside SiriusQT: A Seriously Skilled RAT

Introduction

SiriusQT is advertised as a Windows RAT, but the analyzed sample in this article shows something more complex than a remote administration tool. Under the name, it offers several capabilities in a single implant: remote access, HVNC, browser automation, credential theft, cryptocurrency wallet collection, clipboard monitoring, keylogging, process injection, persistence, anti-analysis checks, and custom encrypted command-and-control traffic.

This article walks through SiriusQT’s server- and client-side components, highlighting what makes it interesting from a reverse-engineering perspective. The goal is not only to list its features, but to show a complex cluster of affiliates, their campaigns and how these components work together and why SiriusQT should be treated as a serious RAT and stealer platform.

Key discoveries

• SiriusQT is a RAT found for sale on dark web forums since April 2026.
• Its author is named “Amonus”, but the seller is “GhostKernel”.
• At least 30 users bought a valid license.
• Licenses can be of different sizes: one month, three months, lifetime.
• Licenses can also be customized by the SiriusQT operator depending on customer requests. 14-day licenses, 45-day licenses, and also 99-day licenses were spotted during the analysis.
• Malicious campaigns were targeting, among others, the United Kingdom, Germany, France, Spain, Italy, and the Netherlands.
• Embeds Hidden Virtual Network Computing (HVNC) for victims’ remote control.
• Strong stealing and keylogging capabilities are also oriented toward extracting data from cryptocurrency wallets and most-used programs.
• Multiple Process Injection Techniques.

Group-IB Threat Intelligence Portal:

Group-IB customers can access our Threat Intelligence portal for more information about the threat actor and malware referenced in this blog:

• SiriusQT Malware
• Amonus Threat Actor
• UpCrypter Malware

Public Malware Detonations

Access free detonation reports linked to SiriusQT and watch malware operate in real time through detailed insights from the Group-IB Malware Detonation Platform:

• SiriusQT Detonation Report

Reseller profile

Despite “Amonus” being referenced as the alleged author of SiriusQT RAT in the about form of the RAT server-side component, no direct evidence linking “Amonus” to the development, promotion, or distribution of the tool was found. The only clearly visible actor connected to the SiriusQT distribution is GhostKernel, a group active in both underground forums and Telegram.

Figure 1. A reseller named GhostKernel is observed to be active on both underground forums and Telegram.

GhostKernel appears to be interested in stolen data, like credential lists, stealer logs, streaming accounts, and email databases. Its activities on Telegram started in February 2026, mainly for advertising the BTMob v4.0, an Android RAT with banking-related features. This suggests GhostKernel is a reseller interested in market diversification through various Windows and mobile malware.

The observed business model appears to be Malware-as-a-Service, with subscription access, customer support, and regular forum promotion, promising hassle-free setup for buyers.

Dark web distribution

Monitoring of the dark web messages shows an active distribution ecosystem around SiriusQT RAT. Most activity occurred on cracked[.]to and crax[.]pro, with a peak between April and May 2026.

Figure 2. Example of a SiriusQT promotional forum post by GhostKernel.

In one observed forum post, GhostKernel advertises SiriusQT v1.0.5 as a Windows RAT and promotes it as a lifetime product priced at US$500. The actor also heavily promotes its Telegram accounts which are used for sales, support, and product updates.

Figure 3. Example of a SiriusQT promotional Telegram post by GhostKernel.

In April 2026, the tool became even more popular, partly because secondary actors were observed to be sharing a cracked version for free.

Figure 4. Example of SiriusQT being offered as cracked software in the wild.

On dark web forums and even GitHub repositories, many distributors of the SiriusQT cracked version were spotted.

This created two parallel markets for the same malware family: one for buyers who want the paid version with support and updates, and the other for lower-skilled or opportunistic users who want free cracked builds (sometimes also enriched with additional malware).

Even though GhostKernel has a dedicated Telegram channel for SiriusQT, and appears to be the only actor offering a paid version for sale, there is no evidence to qualify them as the original distributor. This view is further reinforced given that, on the forums where the sale of this RAT is promoted, all screenshots of the RAT running shows the window title “Sirius Cracked by Claude”.

Figure 5. GhostKernel promotes SiriusQT by using cracked versions in screenshots.

License monitoring

Most non-legit versions came with a Python script that acts as a key generator or a lifetime key generated with the Python script.

Later in this article, we will discuss how this malware stores all the information needed to work properly inside the configuration stub. At this stage, the key point is that the malware configuration includes the license used to generate the SiriusQT client-side component.

The SiriusQT server-side component requires a license in order to work. The license is made up of a 64-character array grouped by two, resulting in a 32-byte token. This field is useful for clustering samples and tracking how the builder was used across different campaigns and operators.

Figur 6. SiriusQT license structure.

In our dataset, we extracted 146 unique licenses. Out of these, 110 were identified as leaked licenses, which represents almost 75% of the observed license pool. The valid licenses show different durations, with 30-day and lifetime licenses being the most visible commercial tiers.

Figur 7. Distribution of SiriusQT license types currently in use.

The license durations are also interesting. Some tiers match the public commercial model, such as 30-day, 90-day, and lifetime licenses. However, other durations are less common, including 14, 28, 45, and 99 days. These unusual license lengths may indicate private agreements between the threat actor and individual buyers.

The relevance of the additional data field is also supported by operator behavior observed in the wild. When an operator used a genuine license and that license expired, they did not simply continue with a keygen-generated license. Instead, they purchased a new genuine license.

One example is an actor who ran at least eight different campaigns between late March 2026 and early June 2026 using two different genuine licenses. After the first 30-day license expired, the actor purchased a new lifetime license approximately one week later:

Two additional operators who purchased genuine licenses also appear to have been satisfied with the product, as both upgraded to lifetime licenses while their existing genuine licenses were still valid.

Moreover, the three different operators were using the same client-server traffic encryption key (COMM_KEY) for all their own campaigns, except for the very first campaigns where maybe no channel encryption was available, so this means that most likely they were using a non-leaked version of SiriusQT.

Worldwide distribution

By looking at publicly available samples, more than 280 SiriusQT clients related to various different campaigns were discovered.

This distribution suggests that SiriusQT was not limited to a single regional market or operator group. By looking at the VirusTotal submissions, the UK, France, Germany, and the Netherlands represent the largest share of the dataset, with more than 50% of the observed locations.

Figur 8. Distribution of SiriusQT clients by VT public submissions.

This geolocation includes real compromised hosts, but also operator-side testing, sandbox executions, and infrastructure used to validate detection rates. This distinction matters because the analyzed SiriusQT builds have a relatively high detection rate. SiriusQT appears to be deployed as a last-stage payload, after the UpCrypter loader with very low detection or claimed FUD capability.

Unlike the previous geolocation chart, the following view is closer to operator telemetry than victim telemetry, because the related analyzed clients contain private IP addresses in their configuration.

Figur 9. Country distribution of SiriusQT samples related to operator tests.

The private IP address in the SiriusQT client configuration suggests that this sample was probably used for internal testing. The operator was likely checking that the implant worked correctly in a controlled local environment before using it against real targets.

By looking at the name of the campaign ID field in the configuration, repeated values such as, “Whatsapp”, “May bots”, and “Chizzy” confirm that multiple RAT clients were generated from the same leaked version of the SiriusQT server.

Other values are more descriptive, like “Mini Stub Mexico”, “UAE”, “China + Taiwan”, and “China – Justified Tools”, which may indicate targeting, lure themes, operator notes, or internal campaign names, but they also could be an indicator of the operator’s intentions.

Date-based values such as “Mar-27_2026” and “April-30_2026” also suggest that the same operator used the campaign id to track a brief campaign. In this case, the same actor used at least two different genuine licenses and obtained the second license (which is lifetime) after having the first one already valid for 99 days. This could mean that the actor saw the potential of this RAT and decided to invest a bit more.

SiriusQT has been observed in relation to other malware families, such as Remcos, XWorm, AsyncRAT and QuasarRAT/NJRAT, since SiriusQT operators may rely on shared or reused infrastructure. One of the command&control found was previously linked with RedLine Stealer. SiriusQT was distributed as final-stage malware using the UpCrypter loader in May 2026 and the same infrastructure was used one year earlier to host another RAT campaign starting with the UpCrypter loader, Fortinet states.

The following graph shows the infrastructure links observed around SiriusQT analyzed samples.

Figur 10. SiriusQT Command&Control relationships with other operators and malware.

Among the command&control servers found in the analyzed SiriusQT samples, an operator is found abusing legitimate Google Cloud infrastructure, this makes detection harder since traffic to Google IP ranges is typically trusted and rarely blocked by corporate firewalls. The IP 34.41[.]139.193 belonging to Google Cloud resources has also been observed in past NetWire campaigns.

The server-side component

The server-side component of SiriusQT is SiriusQT.exe. When double-clicked for the first time, a legal disclaimer form appears, but many users don’t seem to heed the warning 😉 .

The main SiriusQT interface is organized as follows:

Figure 11. Evidence of the server-side component of SiriusQT.

IT comprises several main sections: Clients, Offline Clients, Auto Tasks, Port Manager, Recovery, Builder, Telegram Bot, Settings, and About.

The Clients tab shows the active infected hosts connected to the server. Each client entry includes fields with some fields as summary, such as status, latency, IP address, PC name, username, and operating system. Once the client entry is focused (after a mouse click), the right-side information panel displays additional host details, including hostname, OS, user, privileges, antivirus, CPU, GPU, RAM, uptime, idle time, screen, browser, active window, desktop, architecture, system drive, system directory, and HWID.

For each client entry, the same context menu exposes the following sections:

• The Surveillance menù entry groups features related to Remote Desktop, HVNC, Credential recovery, and traffic redirection.
• The Managers section is designed to inspect and manage files, registry keys, services, processes, scheduled tasks, network state, windows, clipboard content, policies, firewall settings, and storage resources on the remote machine.
• The Miscellaneous menu covers system information collection, command execution, file searching, Windows Defender exclusion management, webpage opening, script execution, and user-interaction features.
• The Shell submenu offers direct command execution through Remote CMD and Remote PowerShell. The Client submenu includes Client Folder, Power, Connection, and Client Details, which are used for client-side management and connection-related actions.

When a client connects for the first time, SiriusQT shows past clients collected. This information is shown in the Offline Clients tab:

Figure 12. Offline client view in the server-side component of SiriusQT.

The past clients’ information is retrieved from the appdata.dat file, inside the Tool-Data folder in the SiriusQT server package. The above evidence means that the actor who shared the leaked version of SiriusQT was conducting an active campaign with the group-ID named as “today,” and different victims were from Russia, China, the Netherlands, the USA, and Germany.

This information is not in clear text inside the appdata.dat file, since the file structure follows this template:

The following is evidence of the appdata.dat file in the leaked SiriusQT server-side component:

Figure 13. SiriusQT appdata.dat structure evidence.

SiriusQT uses a fixed 256-byte keystream for decrypting the appdata.dat, starting from mixing the following constants:

In the appendix, you’ll find the script useful for decrypting appdata.dat.

After deobfuscation, a JSON is obtained containing the shown information and more:

Among the others, the JSON contains juicy information like the license value, the client-server communication key, and the past connected clients, as in the previous evidence.

Another tab that is pretty interesting is the Auto Tasks tab that allows the operator to define automated tasks that can run when a client connects, run one time during the current server session, or run repeatedly based on an interval.

The Recovery tab shows a direct and fast view of the recovered data, like passwords, cookies, wallets, and files:

The Builder tab is used by the operator to configure a new SiriusQT client payload. Like many other malware, it supports endpoint fallback and has a lot of additional and optional features, like Anti-VM Detection, blocking execution if the locale belongs to CIS Regions (Armenia, Azerbaijan, Belarus, Kazakhstan, Kyrgyzstan, Moldova, Russia, Tajikistan, Uzbekistan, and Turkmenistan), encrypting the client, and also building an x86/64 .NET Loader option.

One important feature is the dropdown panel in the Builder tab labeled “Output Format”. The SiriusQT Server-side component is able to build three different client formats: the x64 C++ (native), the .NET Loader x86 and the .NET Loader x64.

In the following paragraphs, they will be discussed.

Overall, this component is a lightweight .NET loader designed to extract an embedded payload from the file overlay and execute it directly from memory, avoiding the need to drop the decoded payload as a separate file on disk.

As the last tab, the Telegram Bot view provides bot-based management options. It includes fields for a bot token and notification channel ID, a polling interval setting, an option to enable the bot controller, and an option to auto-start the bot when SiriusQT is being launched.

The client-side component

The client side of SiriusQT is pretty much not obfuscated; this also explains why there are so many detections from online security engines.

During malware execution and static analysis, several capabilities were identified. This section provides a structured overview of the observed behaviors and summarizes the main findings from the investigation.

Configuration

The resource named Caffee_Config contains the SiriusQT client configuration and is being loaded in the main function of the RAT using the FindResource and LoadResource APIs:

Figure 14. Reading the Caffee_Config resource in SiriusQT client.

Figure 15. Inside the Caffee_Config resource in SiriusQT client.

If the external configuration resource cannot be loaded, the stub falls back to a 4096-byte embedded configuration blob identified by the marker <<SIRIUS_STUB_CONFIG>>. The same parser is used for both the internal resource and the fallback blob:

Figure 16. Alternate SiriusQT marker for loading the configuration.

During the reverse engineering activities has been possible to obtain the meaning of most of the configuration fields:

Mutex

Once the configuration is parsed, the malware ensures that no other copies of the RAT are running on the system by using the mutex. Mutex name “80667f9a-d50c-4c39-a4b5-44ae8aae6d2c” is got from the configuration resource and has been randomly generated by the SiriusQT server at the time of building:

Figure 17. Mutex setup during execution of client version of SiriusQT.

Persistence

The SiriusQT RAT can be configured to start using different startup methods, including:

• a Registry Run key
• a Scheduled Task
• a shortcut in the Startup folder
• a logon script
• the BootExecute registry value (but requires the malware to have administrator privileges), which runs before normal user logon
• Windows Default User profile

These options are up to the operator to be activated during the stub building phase. They allow the SiriusQT to adapt to different environments and privilege levels.

These options are up to the operator to be activated during the stub building phase. They allow the SiriusQT to adapt to different environments and privilege levels.

1. If the registry run key option is enabled, the sample implements user-level persistence through the HKCU\Software\Microsoft\Windows\CurrentVersion\Run registry. If no custom value name is provided, it uses the Windows Update name. This allows the payload to be launched automatically when the user logs in, without requiring any administrative privileges.
2. When the schedule task option is enabled the SiriusQT client side component builds an XML task definition and creates it using schtasks.exe. The generated task is configured with a logon trigger, intended to run when the user logs in. If no custom task name is provided, the malware uses the name Windows Update.
3. When the Startup Folder option is enabled, the RAT initializes COM interface and creates a Shell Link object. It sets the shortcut target to the configured payload path, assigns the description Windows Update, and then saves the shortcut as a .lnk file, using WindowsUpdate.lnk as the default name.
4. The RAT implements persistence through the UserInitMprLogonScript mechanism. When the Logon Script option is enabled, the RAT creates a batch script named logon.cmd, in the directory provided in the configuration stub. The script contains a command that starts the SiriusQT client side component. After creating the script, the malware opens HKCU\Environment and sets the UserInitMprLogonScript value to the path of the generated logon.cmd file. This causes the script, and therefore the RAT, to be executed when the user logs in. This is a user-level persistence technique and does not require administrative privileges.
5. When the Boot Execute option is enabled, the malware attempts to use an administrator-level persistence and more stealth method than normal user-level startup persistence. It first checks whether it is running with administrative privileges. If so, it opens the Session Manager registry key HKLM\SYSTEM\CurrentControlSet\Control\Session Manager and queries the existing BootExecute value. By appending an additional entry to it, the SiriusQT RAT can attempt to execute code during system startup.
6. When the SiriusQT has the Default User persistence option it poisons the Windows default User Profile. This is because Windows uses C:\Users\Default as a template when creating new user profiles. The file C:\Users\Default\NTUSER.DAT contains the registry hive that will be used as the base for the new user’s HKEY_CURRENT_USER hive. The SiriusQT abuses this behavior by loading the Default User registry hive with RegLoadKeyA, modifying it, and then unloading it with RegUnLoadKeyA. While the hive is loaded, the malware writes an autorun-style registry value. If no custom value name is found in the configuration, the value is named Windows Update. The data written by the RAT uses  %APPDATA%, this means the RAT attempts to seed persistence both in the current user profile and into future user accounts created on the same machine.

Dynamic API resolution

Once the SiriusQT client ends setting the persistence mechanism, it starts walking the PEB structure, enumerating module exports, and resolving the API using a custom 32bit FNV-1 hash algorithm.

Figure 18. FNV-1 hash algorithm in SiriusQT client side component.

In the above evidence, the seed is 0x7158B20F and the target hash is 0x62A6C3F7,  which resolves to CreateThread API. Another function was found using the same algorithm but with the seed 0x29f1276c and resolving the 0x706ECA3E hash, corresponding to LoadLibraryA.

A python script is provided for fast hash computation:

The client dynamically resolves LoadLibraryA and GetProcAddress through PEB, using the same FNV-1a like hashing algorithm, loads iphlpapi.dll, and obtains the address of NotifyAddrChange API. This allows the main C2 server to be automatically reconnected after the network stops working or the internal IP address changes.

Payload execution

SiriusQT also includes multiple ways of doing process injection and in-memory payload execution. It references APIs and techniques such as WriteProcessMemory and VirtualProtectEx. In addition, it resolves dynamically API like NtQueryInformationProcess and NtQueueApcThread.

The SiriusQT server-side component let choose between Process Hollowing and different injection techniques like QueueUserAPC / Early-Bird Injection and Remote Thread Injection using NtCreateTreadEx or CreateRemoteThread APIs, designed to run both EXE and DLL x32/x64., available on the client-side component.

The payload execution form also allows choosing the running target process on the client:

Figure 19. Remote execution option panel in SiriusQT server-side component.

HVNC

Like many modern RATs, SiriusQT RAT provides an HVNC feature. HVNC, or Hidden VNC, gives the attacker a remote graphical session inside a hidden desktop that the victim does not normally see.

The HVNC protocol between the client and the server is discussed in the Command and Control section.

Before that HVNC session starts, the SiriusQT server-side component delivers an additional DLL module to the SiriusQT client, named HVNCInjection.x64.dll. It supports the hidden session by installing hooks, redirecting selected file-system paths, and injecting itself into child processes created during the HVNC session.

The HVNCInjection.x64.dll module has the following SHA-256 hash:

• c206fa613257110b0522b60b402ca0b35da2cb126113e47b67543ba3ff93c53c

This DLL contains a reflective loading mechanism. This means that the HVNCInjection.x64.dll could be loaded directly from memory instead of being loaded from disk by the Windows loader.

The reflective loader locates the DLL image in memory, validates the PE headers, allocates memory for the new image, copies headers and sections, resolves imports, applies relocations, and finally calls the DLL entry point.

Inside the reflective loader stage, the loader dynamically resolves Windows APIs. It walks the loaded module list from the PEB and computes a ROR13-based hash over module names. For example, the comparison with the hash value 0x6A4ABC5B identifies kernel32.dll library.

Figure 20. ROR13 based hash algorithm in HVNC helper module named HVNCInjection.x64.dll.

The HVNCInjection.x64.dll DLL uses MinHook to install userland hooks. MinHook is a small user-mode API hooking library for Windows. It allows the SiriusQT client-side component to intercept API calls, forcing the execution first to the DLL’s custom handler. The handler can inspect and modify the parameters, then call the original API through a trampoline created by MinHook.

When the DLL is loaded the following APIs are hooked:

• NtCreateFile
• NtOpenFile
• NtDeleteFile
• NtSetInformationFile
• NtQueryAttributesFile
• NtQueryFullAttributesFile

This means the DLL can redirect file creation, file opening, file deletion, rename or move operations, and file attribute queries.

The DLL also installs hooks on:

• NtQueryDirectoryFile
• NtQueryDirectoryFileEx

However, for these two last APIs the handler does not modify the returned directory listing, it simply calls the original function, so the handler acts like a wrapper.

The DLL also provides a way to do filesystem path redirection based on two environment variables RDI_SEARCH_PATH and RDI_REPLACE_PATH.

When a process tries to access a file path, the hook checks whether that path matches the value configured in RDI_SEARCH_PATH. If it does, the DLL changes the path by using the value configured in RDI_REPLACE_PATH. The process believes it is accessing the original path, but the real Windows API receives the replaced path.

For example, if the two environment variables are configured like the following:

then a request for accessing the “C:\Users\Admin\Desktop\file.txt”, can be redirected to the “C:\Users\Admin\AppData\Local\Temp\HiddenDesktop\file.txt” .

This mechanism is transparent to the process that is trying to access the “C:\Users\Admin\Desktop\file.txt”, but the real API call uses the redirected path once the handler modified it.

Using HVNC, the SiriusQT operator can interact with applications installed on the client machine, while selected file paths are transparently redirected to a separate location. This can help isolate the HVNC environment from the victim’s real desktop or profile paths, depending if the two path variables are enabled and how they are configured.

The SiriusQT client embeds the code for launching a Chromium-based browser instance for the HVNC module:

Figure 21. Command line for launching the chromium based browser in the SiriusQT client.

It builds a dedicated browser profile path, checks whether the profile directory exists, and prepares it if needed. The browser is then started with a custom “--user-data-dir” and an inline “data:text/html” page displaying “Welcome to HVNC !”. The command line also is intended for disabling sandboxing, GPU acceleration, audio, plugins, 3D APIs, and other rendering features, just like for doing as little noise as possible to run a HVNC environment.

When the operator executes the browser app (for instance Edge) in the HVNC session, he can also clone the browser profile resulting in complete client session stealing:

Figure 22. HVNC panel in SiriusQT server-side component.

Figure 23. Child injection in the HVNC helper module named HVNCInjection.x64.dll.

The code works in the following steps:

1. finds the ReflectiveLoader export inside the DLL blob
2. allocates memory in the child process with VirtualAllocEx
3. writes the DLL blob into the child process with WriteProcessMemory
4. starts a remote thread with CreateRemoteThread passing the remote address of ReflectiveLoader as the thread start address (v11 variable)

Despite the presence of such described implants, during our analysis no evidence of hooking or path redirection was seen. The HVNCInjection.x64.dll appears to be loaded but not used.

Stealing activities

The Recovery window on the SiriusQT server-side component is a credential collection panel. It allows the operator to select specific data sources to target, such as cryptocurrency wallets, messengers, social applications, browsers, VPN clients, games, password managers, cloud storage, developer tools, RDP, and mail clients, among more than 100 different checkboxes:

Figure 24. Credential recovery interface in SiriusQT server-side component.

The credential-recovery functionality can handle modern Chromium secrets, including AES-GCM-protected passwords. For example the following snipped is able to restore encrypted Chromium/Electron Discord tokens marked by the “dQw4w9WgXcQ:” prefix:

Figure 25. Code snippet to handle AES-GCM (Advanced Encryption Standard in Galois/Counter Mode) using ChainingMode.

The SiriusQT client doesn’t just steal but also checks whether the stolen tokens are still valid. It’s the case for Discord related credentials: the RAT has a custom function to verify stolen credentials by sending requests directly to a Discord endpoint using a custom “Mozilla/5.0” User-Agent:

Figure 26. Code snippet for verifying leaked Discord accounts by SiriusQT client.

Clipboard monitoring and keylogging

Clipboard monitoring logic periodically opens the Windows clipboard and checks whether Unicode text is available. If clipboard text is present, the routine locks the clipboard handle, converts the wide-character string to UTF-8 using code page 65001, closes the clipboard, and passes the resulting string to a pattern-matching routine.

Figure 27. Clipboard pattern matching functionality in SiriusQT client.

A user activity monitoring loop for a specified window is also available. It installs a low-level keyboard hook using SetWindowsHookExA with hook type WH_KEYBOARD_LL (0xD), then keeps a Windows message loop active through PeekMessageW, TranslateMessage, and DispatchMessageW APIs.

The routine periodically retrieves the current Windows foreground window and stores its title.

SiriusQT is also able to match the active window title against configured patterns. Once the logging activity is done, it removes the hook.

As well as many others RAT it also pretty prints special buttons for proper keylogging activity.

Command & Control

The SiriusQT RAT communication channel is encrypted at the payload level. The protocol uses a simple TCP framing format where each message starts with a 4-byte little-endian payload length. This length field is transmitted in cleartext and is used only to determine how many bytes must be read from the TCP stream. The following payload bytes are encrypted.

Figur 28. SiriusQT Client – Server encrypted communication channel format.

The same frame structure is used in both directions. Only the payload is encrypted.

SiriusQT does not appear to use a standard encryption algorithm such as ChaCha20 or Salsa20 for its network traffic, even though the binary contains the string “expand 32-byte k”.

The SiriusQT communication is encrypted using a custom stream-cipher-like routine for payload transport and receiving data.

While looking at the SiriusQT client-side component, the function at 0x1400D82C0 receives a cipher context, a buffer, and a buffer size, then modifies the buffer in place.

Figure 29. SiriusQT Client – Server encrypting clear-text buffer.

The cipher context is made up of:

• the 32-byte communication key stored in the configuration
• the current 64-bit packet counter

For each payload, the 64-bit counter is read from the context and then incremented:

Figure 30. Cipher context for clear-text buffer encryption.

The encryption routine combines the counter, the current payload offset, and values from the cipher context to derive temporary 64-bit values.

These values are then mixed using two constants associated with the MurmurHash3 fmix64 finalizer algorithm:

The resulting mixed values are used to build a 16-byte keystream block. This keystream block is then XORed with the cleartext buffer.

Below is the Python implementation for decrypting messages between the SiriusQT client and server:

The embedded communication key is also useful for tracking and clustering SiriusQT samples. Because the key is stored inside the generated client configuration and also resides in the SiriusQT server-side component folder, in the “connection.key” file, samples using the same key can often be linked to the same leaked server and so even the builder instance. Reused keys across otherwise different samples may indicate non-legitimate SiriusQT server usage.

After decryption, the payload becomes:

Figur 31. SiriusQT Client – Server command structure after traffic decryption.

All the commands sent by the SiriusQT server-side component are one byte in size and for many of the commands there is no additional payload. More complex commands use 1 byte opcode as well but also use an opcode-specific body format for sending custom structures or embedded PE files.

For example, the simplest packet with one byte payload size is the one with the opcode 0x1, which is a kind of heartbeat or keepalive.

When a new client connects to the SiriusQT server-side component, the 0x2 opcode is used to ask the client to send the server data for victim host registration:

Figure 32. Host registration information structure in SiriusQT client.

The SiriusQT client outbound message after receiving the 0x2 opcode from the server, contains a full host registration profile used to give the threat actor a summary of the compromised host.

It includes the following information:

• 4 bytes HWID generated by the RAT
• Machine name
• Username
• operating system version and build
• CPU model
• display adapters
• memory information
• Group-Identification
• privilege level,
• current process,
• active window context
• hostname,
• current system32 directory
• screen resolution
• Architecture
• detected security product
• uptime values

Also the 0x2 opcode is an update poll or frame request that is sent to the client every time the operator at the SiriusQT server-side component switches the focus to that client.

After receiving this 0x02 packet, the client replies with a client-to-server packet using opcode 0x03, that carries the client-side update data and JPEG screenshot blob.

Client-to-server traffic uses the same framing model but different opcode semantics.

Below is a list of the most important server-to-client opcodes found:

As can be seen from the table some opcodes use a structured body instead of a single-byte command.

The Remote Shell module uses three related opcodes:

1. Opcode 0x20 starts a shell process and carries the interpreter name as an ASCII string, such as cmd or powershell. So payload size can be 4 or 11 bytes:

2. Opcode 0x21 sends input to the active remote shell. The body contains the command text as ASCII. For example, the command whoami\n is encoded as:

3. Opcode 0x22 closes the remote shell session, without  carrying any additional body

The Password Recovery module uses opcode 0x38. Its body is a 16-byte little-endian bitmask. Each bit corresponds to a specific target application or credential source selected in the controller UI. For example, consider the following:

The HVNC module uses a dedicated opcode flow rather than a single standalone command. The observed sequence is the following:

Figur 33. SiriusQT client-server dialogue during HVNC session.

The HVNC session starts with the server sending the opcode 0x47 with the HVNC PE/module payload. Immediately after that, the server sends the opcode 0xE0 with the value 0x46 as a payload

After receiving the HVNC module and initialization command, the client sends the server the 0x47 acknowledgement opcode. Again the client sends the server the  0xE7 opcode with the ASCII message “OK: HVNC started”:

Once the module is ready, the server sends the opcode 0xEB.without additional payload to act as the HVNC start command.

The client replies with opcode 0xEA with one byte 01 acknowledgement:

After this point, the client begins sending packets starting with opcode 0xE6.

The 0xE6 opcode is used by the client to send visual frame updates to the server. The packet contains a tile-based update structure. The header includes the screen resolution, the number of updated tiles, and the size of the following encoded data stream.

A tile is a portion of the client HVNC screen. The client does not always send the entire screen. This depends on the update_type byte, value 0x11 means full screen update, while 0x10 means partial screen update. In this HVNC session, the screen is divided into a grid of fixed-size tiles and the client sends only the tiles that changed. Since the tile table in the payload contains pairs of X-Y coordinates that are aligned to 0x40 (which is 64), that means the frame is built on a 64×64 tile grid.

The remaining bytes contain the encoded frame data for those tiles.

Operator runtime interaction with the HVNC session is performed through the 0xE2 opcode. This opcode requires a payload variable in size, encoded like ASCII string not NUL terminated and containing command and arguments splitted by the “*” character:

For example when the operator moves the mouse on the remote HVNC, the resulting command would be the following one:

This would mean the server is telling the client “Move the hidden desktop mouse pointer to coordinate 613, 10”

Other HVNC events related to server operator mouse activity are the following:

To stop the HVNC session, the server uses opcode 0xE1. After the server sends the client a one byte packet with 0xE1 opcode, the client replies with another 0xE7 opcode starting message, with the following payload “OK: HVNC stopped”

This indicates that opcode 0xE7 is used by the client to report HVNC status messages back to the SiriusQT server side component.

Another important action that the threat actor could do is to execute a payload on the client. This is accomplished by sending the 0xD4 opcode. The payload starts with a 16-bit little-endian target path length. If the length is non-zero, it is followed by the target process path. The remaining bytes contain an embedded PE file.

If the execution is fine, the client replies with the 0xD4 opcode with the message “OK: PE injected successfully” as a payload, confirming successful PE injection.

Different client formats

When dealing with the Builder view of SiriusQT, three different output formats were available to the operator to be used.

Besides the 64-byte C++ payload discussed in this blog, also the .NET Loaders, both 32 and 64 bytes, are worth mentioning.

When an operator chooses to produce a SiriusQT client compatible with .NET structure, the client is still x64 based, but packed.

In fact the .Net loader reads its own executable from disk using Assembly.GetExecutingAssembly().Location, then locates the appended overlay data with FindOverlayOffset(). The overlay starts with an 8-byte header containing a 32-bit XOR key followed by a 32-bit encoded payload size. The remaining overlay bytes contain the encoded payload.

Figur 34. SiriusQT .NET Loader just after final payload decryption.

The SiriusQT client payload is decoded by XORing each byte with the 4-byte key repeated across the encoded payload.

Then the .NET loader allocates memory with VirtualAlloc, copies the decoded payload into the allocated region and starts execution using CreateThread API, avoiding the need to drop the decoded payload as a separate file on disk.

From sample to configuration: automated analysis on Group-IB MXDR

A recent SiriusQT sample shows how Group-IB MXDR works in practice. The stub file was detonated in our analysis environment on a Windows 11 x64 system and confirmed the malicious verdict.

Figur 35. SiriusQT malicious verdict from Group-IB MXDR.

The configuration gives a clear view of the attacker’s setup. The primary command-and-control server is 23.132.164[.]14 on the default port 4449. The malware installs itself as %APPDATA%\Microsoft\svchost.exe, to look like a legitimate Windows process. If that fails, it falls back to %TEMP%\msupdate\svchost.exe. The configuration also contains a group tag and a perpetual license created on May 2, 2026, which are useful for tracking the operator over time.

Figur 36. SiriusQT compact configuration available on Group-IB MXDR.

For defenders, this means fast and practical results. The C2 address, install paths, and file names can be used right away to block the threat and to hunt for earlier infections in the customer’s environment. This shortens the time between detection and response.

Figur 37. SiriusQT fully extracted configuration on Group-IB MXDR.

Readers can access this public detonation report on Group-IB MXDR and review the complete findings, including the process tree, triggered signatures, and fully extracted configuration.

Conclusion

SiriusQT illustrates how modern commodity RATs continue to evolve around the operational needs of financially motivated threat actors. Operators are not only looking for basic remote access capabilities, but for tools that are stable, commercially supported, feature-rich, and capable of maintaining access while reducing detection opportunities.

At the same time, the analyzed client shows high detection rates, which limits its effectiveness when deployed directly as a standalone binary. This suggests that successful operators would likely pair SiriusQT with an external loader, packer, or fileless execution chain to reduce exposure during initial execution and improve the chances of establishing a working infection.

The HVNC implementation is particularly relevant because it could provide operators with an isolated hidden desktop environment. HVNC is not an auxiliary feature, but a core capability intended to support stealthy interactive activity on infected systems. This type of functionality is increasingly valuable in the MaaS RAT ecosystem, where operators look for tools that enable hidden browser-based fraud rather than opportunistic credential theft.

Recommendations

• Stay alert to any request asking you to download, open, or execute files, especially when the request comes from emails, messaging platforms, fake support pages, cracked software websites. Always verify the source before proceeding to reduce the risk of exposing your device, credentials, or organization to malware.
• Enforce Multi-Factor Authentication (MFA) across all critical services and monitor for suspicious login activity. While session hijacking through stolen cookies or cloned browser profiles can bypass password-based authentication, MFA still increases the difficulty for attackers attempting to gain or maintain unauthorized access.
• Keep operating systems, browsers, password managers, and security tools regularly updated. Browser security features, such as Chrome’s App-Bound Encryption, are designed to reduce unauthorized access to stored secrets, but their effectiveness depends on timely updates and proper endpoint protection.
• Maintain visibility into endpoint and network activity. Even commodity RATs can provide operators with remote access, credential theft, file management, proxying, and hidden desktop capabilities. Monitoring unusual outbound connections, suspicious browser activity, and unexpected execution behavior can help identify compromise earlier.
• Strengthen your security posture with reliable threat intelligence like Group-IB’s Threat Intelligence. Access to timely intelligence on emerging malware families, attacker infrastructure, delivery methods, and social engineering trends can help you identify risks sooner and respond more proactively.

MITRE ATT&CK

YARA

Yara rule for SiriusQT server

Yara rule for SiriusQT native client

Yara rule for SiriusQT Loader client

Yara rule for HVNCInjection.x64.dll HVNC helper module

Indicators of Compromise (IOCs)

File Indicators:

Network indicators:

APPENDIX A: Script for appdata.dat file decryption

The following python script is made for fast XOR based symmetric decryption of the appdata.dat file used in SiriusQT server component:

DISCLAIMER: All technical information, including malware analysis, indicators of compromise and infrastructure details provided in this publication, is shared solely for defensive cybersecurity and research purposes. Group-IB does not endorse or permit any unauthorized or offensive use of the information contained herein. The data and conclusions represent Group-IB’s analytical assessment based on available evidence and are intended to help organizations detect, prevent, and respond to cyber threats.

Group-IB expressly disclaims liability for any misuse of the information provided. Organizations and readers are encouraged to apply this intelligence responsibly and in compliance with all applicable laws and regulations.

This blog may reference legitimate third-party services such as Telegram and others, solely to illustrate cases where threat actors have abused or misused these platforms.

This material is provided for informational purposes, prepared by Group-IB as part of its own analytical investigation, and reflects recently identified threat activity.

All trademarks referenced herein are the property of their respective owners and are used solely for informational purposes, without any implication of affiliation or sponsorship.