{
	"id": "2b669b80-8a69-4146-b820-ac1f4d3c1305",
	"created_at": "2026-04-06T00:08:26.033732Z",
	"updated_at": "2026-04-10T03:21:57.291486Z",
	"deleted_at": null,
	"sha1_hash": "0cfc49eacece7037e8bad568e7ea993816fb2b62",
	"title": "Quasar Open-Source Remote Administration Tool | CISA",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 120777,
	"plain_text": "Quasar Open-Source Remote Administration Tool | CISA\r\nPublished: 2019-02-14 · Archived: 2026-04-05 22:59:23 UTC\r\nQuasar is a publically available, open-source RAT for Microsoft Windows operating systems (OSs) written in the\r\nC# programming language. Quasar is authored by GitHub user MaxXor and publicly hosted as a GitHub\r\nrepository. While the tool can be used for legitimate purposes (e.g., an organization’s helpdesk technician remotely\r\naccessing an employee’s laptop), the Cybersecurity and Infrastructure Security Agency (CISA), is aware of APT\r\nactors using Quasar for cybercrime and cyber espionage campaigns.\r\nQuasar was first released in July 2014 as “xRAT 2.0.” In August 2015, xRAT was renamed “Quasar” and released\r\nas v1.0.0.0. For this report, the National Cybersecurity and Communications Integration Center (NCCIC), part of\r\nCISA, analyzed Quasar version 1.3.0.0, which was released on September 28, 2016, and is the latest stable version\r\navailable on GitHub. This report does not reflect any changes Quasar’s author has made to the tool’s source code\r\nsince the release of v1.3.0.0.\r\nOpen-source reports state that some APT actors have adapted Quasar and created modified minor (1.3.4.0) and\r\nmajor (2.0.0.0 and 2.0.0.1) versions.[1] ,[2] NCCIC has not determined the exact difference between these\r\nversions and v1.3.0.0. Therefore, NCCIC cannot definitively say whether the detection and mitigation\r\nrecommendations provided in this report will work effectively against APT actor-modified versions of Quasar.\r\nHigh Level Architecture\r\nQuasar uses a client-server architecture that enables one user to remotely access many clients. The server is\r\nresponsible for creating client binaries and managing client connections. Users then interact with connected clients\r\nthrough the server’s graphical user interface (GUI).\r\nNote: Quasar does not contain software vulnerability exploits. Threat actors must leverage other tools or methods\r\nto gain access to a target host before they can use Quasar.\r\nRequirements\r\nQuasar requires a Microsoft .NET Framework 4.0 (or higher) Client Profile. The Quasar client and server will run\r\non the following OSs (32- and 64-bit):\r\nWindows XP Service Pack 3,\r\nWindows Server 2003,\r\nWindows Vista,\r\nWindows Server 2008,\r\nWindows 7,\r\nWindows Server 2012,\r\nWindows 8/8.1, and\r\nWindows 10.\r\nhttps://www.cisa.gov/news-events/analysis-reports/ar18-352a\r\nPage 1 of 10\n\nQuasar Server\r\nThe Quasar server component is responsible for\r\nListening for and handling client connections (e.g., catching new connections, terminating connections);\r\nManaging connected clients (e.g., retrieving files, showing the screen, killing processes); and\r\nConfiguring and building client executables.\r\nFigure 1 shows the Quasar server component GUI. Quasar users interact with the server and, in turn, its clients,\r\nthrough the GUI. Each client’s entry is listed individually and includes the client’s Internet Protocol (IP) address,\r\nusername, Quasar client version, connection status, user status, country, OS, and account type. The Quasar user\r\ninitiates client interactions by right-clicking an individual client row, which opens a pop-up menu with available\r\ncommands.\r\nFigure 1: Quasar screenshot – example of a Quasar server with a connected client\r\nThe server component builds client executables that the Quasar user can run on target hosts. The client builder\r\nfeature allows the Quasar user to select from different options and attributes (see table 1).\r\nTable 1: Quasar client builder feature options and attributes\r\nhttps://www.cisa.gov/news-events/analysis-reports/ar18-352a\r\nPage 2 of 10\n\nOption Default Option Description\r\nBasic Settings\r\nClient tag None\r\nRepresents the name for the client instance.\r\nThis value is displayed in the connection table\r\n(see figure 1) of the Quasar server GUI once\r\nthe client connects\r\nMutex\r\nQSR_MUTEX_[18 character\r\nalphanumeric upper and lowercase\r\nstring]\r\nSets the file mutual exclusion object (mutex)\r\nto prevent the same host being infected\r\nmultiple times\r\nConnection Settings\r\nCallback IP None Sets the server IP for the client connection\r\nCallback domain None Sets the domain for the client connection\r\nCallback port 4782\r\nSets the Transmission Control Protocol (TCP)\r\nport callback to “on”\r\nPassword 1234\r\nSets the password for Advanced Encryption\r\nStandard (AES) encryption\r\nConnection retry 300ms\r\nSets how often the client will attempt to\r\ncallback if they are not connected\r\nInstallation Settings\r\nInstall client Off\r\nSets the default for whether or not the client\r\nwill install on a host\r\nBase installation\r\npaths\r\n%AppData%\r\nProgram Files*\r\nWindows\\SysWOW64 *\r\nThe location where the client file will be\r\ninstalled on a host. This field is limited to the\r\noptions listed. Starred items (*) require\r\nadministrator privileges\r\nInstall\r\nsubdirectory\r\nSubDir\r\nMakes a customizable subdirectory within the\r\nbase installation path\r\nInstall name Client\r\nThe name of the client file. This file must be\r\n.exe\r\nRun client when\r\nthe computer\r\nstarts\r\nOff\r\nA checkbox that, if checked, will add the\r\nQuasar client as an AutoRun via Registry Key\r\nor Scheduled Task\r\nhttps://www.cisa.gov/news-events/analysis-reports/ar18-352a\r\nPage 3 of 10\n\nStartup name Quasar Client Startup Customizable free text field\r\nThe Quasar user can also set metadata to be embedded in the executable, such as the author, organization,\r\ncopyright, year, and version.\r\nQuasar Client\r\nQuasar client instances are built by the server component. Based on multiple client builds, each with different\r\nconfigurations, the client size is consistently 349KB. Once it is distributed to a target host, the client needs to be\r\nexecuted before it can call back to the server. Client execution is invisible to the target host user and does not\r\ngenerate any visible windows or notifications on the target host, except in cases where the client becomes\r\nunresponsive. Once running on a target host, the client  process is visible to the target host user via Windows Task\r\nManager or a similar process management program.\r\nNetwork Traffic\r\nQuasar encrypts communications using the AES algorithm. The client builder hardcodes a Quasar user-chosen,\r\npre-shared key to be used in command and control (C2) communications. The server must be configured to listen\r\non the callback port and use the pre-shared key. (Quasar’s author has stated [via GitHub] that they would like to\r\nupdate Quasar to use Transport Layer Security for C2 encryption in the future.)\r\nAfter the TCP handshake is completed, all traffic between the server and client is encrypted. The entropy of AES\r\nciphertext makes it impossible to write a pattern to detect this content. Quasar uses the first 4 bytes of the TCP\r\npayload to track the payload’s total size in little-endian format. This size-tracking pattern is distinctive to Quasar\r\nnetwork traffic. As shown in figure 2, the first 4 bytes of the TCP payload contain 0x40000000 or 64 decimal in\r\nhexadecimal notation. Subtracting the tracking bytes (4 bytes) from the total TCP payload (68 bytes) results in an\r\nactual payload size of 64 bytes.\r\nFigure 2: Quasar screenshot – C2 traffic\r\nThe distinctive first 4 bytes of the payload can be used to identify Quasar traffic. Specifically, the first 4 bytes can\r\nidentify the first packet sent from the server to the client following the TCP handshake. This packet is used to\r\ninitiate the server/client authentication process. See table 2 for a description of the attributes of the first packet\r\nfrom the server to the client following the TCP handshake. This information can be used to identify potential\r\nQuasar activity on a network.\r\nTable 2: Quasar packet attributes\r\nhttps://www.cisa.gov/news-events/analysis-reports/ar18-352a\r\nPage 4 of 10\n\nType Attribute\r\nTCP Flag PSH and ACK\r\nTotal Size 122 bytes\r\nTCP payload size 68 bytes\r\nFirst 4 bytes of payload 0x40000000\r\nClient Network Traffic\r\nQuasar allows the user to gather host system information. As part of the client connection setup, the client\r\nattempts to discover its geolocation—including its Wide Area Network (WAN) IP address—by sending an HTTP\r\nGET request to the Uniform Resource Locator (URL) ip-api[.]com/json/ with User-Agent string:\r\nMozilla/5.0 (Windows NT 6.3; rv:48.0) Gecko/20100101 Firefox/48.0 .\r\nThis User-Agent string mimics a Mozilla Firefox 48 browser running on Windows 8.1. This User-Agent string\r\nwould likely stand out as unique in a corporate network environment, and its presence could be a high-confidence\r\nindication of Quasar activity.\r\nIf the client does not receive a response from this lookup, the client attempts to retrieve WAN IP information from\r\nfreegeoip[.]net and api[.]ipify[.]org , respectively. The User-Agent string remains consistent across all\r\nattempts.\r\nQuasar users can also direct the client to access websites. These requests can be set as visible to the host user via a\r\nbrowser window that opens or invisible to the host user via the C# WebRequest class. Requests that are visible to\r\nthe host user use the User Agent string from the Quasar user’s browser. Requests that are marked as invisible to\r\nthe host user are sent with User-Agent string:\r\nMozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.75.14 (KHTML, like Gecko)\r\nVersion/7.0.3 Safari/7046A194A .\r\nThis User-Agent string mimics an Apple Safari 7.0.3 browser running on Mac OS X 10.9.3. The use of Mac OS X\r\nas the operating system is interesting because Quasar can only be run on Windows. NCCIC has leveraged\r\nQuasar’s use of Mac OS X to limit false positives in the Snort signatures for this activity.\r\nThe User-Agent strings listed in this section are set by the server component when the client file is built. The\r\nstrings can only be changed by altering the User-Agent string in the server source code. All clients built with a\r\nserver component compiled from unaltered Quasar v1.3.0.0 source code contain these User-Agents.\r\nClient Installation\r\nQuasar’s client builder limits the base directories in which the client may be placed. The three base directories in\r\nwhich the Quasar client builder can place itself are\r\nhttps://www.cisa.gov/news-events/analysis-reports/ar18-352a\r\nPage 5 of 10\n\nProgram Files (requires administrator privileges),\r\nWindows\\SysWOW64 (requires administrator privileges), and\r\n%APPDATA%.\r\nFigure 3: Quasar sceenshot – client installation settings\r\nQuasar users can specify which subdirectory within the base directory to place the client executable (as shown in\r\nfigure 3). Quasar users can also specify the name of the executable. Both the client executable and the\r\nsubdirectory can be hidden from the target host user during installation by a Windows application programming\r\ninterface call that sets one of the file’s attributes to “hidden.” The “hidden” setting only hides files from the target\r\nhost user’s view in Windows File Explorer.\r\nPersistence\r\nQuasar achieves persistence by executing on startup, as seen in the source code shown in figure 4. To achieve\r\npersistence, Quasar uses two methods: scheduled tasks and registry keys. If the client process has administrator\r\nprivileges, the client will generate a scheduled task via schtasks . The scheduled task is generated using the task\r\nname created in the client builder. The schedule task runs after the host user logs on, executes with the highest run\r\nlevel (i.e., the highest level of privilege), and suppresses any errors related to creating the task. If the process does\r\nnot have administrator privileges, the scheduled task will only add a registry value. That registry value is added to\r\nthe following key:\r\nHKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run .\r\nThe value name is then configured in the client builder, and the client adds its current path as the startup program.\r\nif (WindowsAccountHelper.GetAccountType() == \"Admin\")\r\n            {\r\n                try\r\n                {\r\n                    ProcessStartInfo startInfo = new ProcessStartInfo(\"schtasks\")\r\n                    {\r\n                        Arguments = \"/create /tn \\\"\" + Settings.STARTUPKEY + \"\\\" /sc ONLOGON /tr \\\"\" +\r\nClientData.CurrentPath + \"\\\" /rl HIGHEST /f\",\r\n                        UseShellExecute = false,\r\n                        CreateNoWindow = true\r\n                    };\r\n                    Process p = Process.Start(startInfo);\r\nhttps://www.cisa.gov/news-events/analysis-reports/ar18-352a\r\nPage 6 of 10\n\np.WaitForExit(1000);\r\n                    if (p.ExitCode == 0) return true;\r\n                }\r\n                catch (Exception)\r\n                {\r\n                }\r\n                return RegistryKeyHelper.AddRegistryKeyValue(RegistryHive.CurrentUser,\r\n                    \"Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run\", Settings.STARTUPKEY,\r\nClientData.CurrentPath,\r\n                    true);\r\n            }\r\n            else\r\n            {\r\n                return RegistryKeyHelper.AddRegistryKeyValue(RegistryHive.CurrentUser,\r\n                    \"Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run\", Settings.STARTUPKEY,\r\nClientData.CurrentPath,\r\n                    true);\r\nFigure 4: Source code from Quasar/Client/Core/Installation/Startup.cs\r\nPrivilege Escalation\r\nQuasar allows the tool user to escalate the client’s running privileges, as seen in the source code shown in figure 5.\r\nTo escalate the client’s running privileges, Quasar attempts to launch a command prompt ( cmd.exe ) as an\r\nadministrator. The elevated command prompt then relaunches the client. The client inherits the parent process’\r\nnow-elevated privileges. If the Window’s User Account Control (UAC) is configured, this method generates a\r\nUAC pop-up window on the target host, which asks the target host user to confirm the process of running the\r\ncommand prompt as the administrator. \r\nif (WindowsAccountHelper.GetAccountType() != \"Admin\")\r\n            {\r\n                ProcessStartInfo processStartInfo = new ProcessStartInfo\r\n                {\r\nhttps://www.cisa.gov/news-events/analysis-reports/ar18-352a\r\nPage 7 of 10\n\nFileName = \"cmd\",\r\n                    Verb = \"runas\",\r\n                    Arguments = \"/k START \\\"\\\" \\\"\" + ClientData.CurrentPath + \"\\\" \u0026 EXIT\",\r\n                    WindowStyle = ProcessWindowStyle.Hidden,\r\n                    UseShellExecute = true\r\n};\r\nFigure 5: Source code from Quasar/Client/Core/Commands/SystemHandler.cs\r\nSummary\r\nQuasar, a legitimate open-source remote administration tool (RAT), has been observed being used maliciously by\r\nAdvanced Persistent Threat (APT) actors to facilitate network exploitation.\r\nThis Analysis Report provides information on Quasar’s functions and features, along with recommendations for\r\npreventing and mitigating Quasar activity.\r\nSolution\r\nNetwork defenders can detect Quasar activity by monitoring network traffic for its unique pattern, the registry key\r\nit edits for persistence, mutexes for strings that follow the default Quasar pattern, and the directories where Quasar\r\ninstalls itself. Commercial antivirus programs detect most Quasar client binary builds as malicious.\r\nSnort Signatures\r\nSignature 1: TCP Payload Size Tracking\r\nThis signature matches on a server-to-client packet with a TCP payload length of 68 bytes and the first 4 bytes\r\nmatching the size tracking sequence. NCCIC observed this packet as the first packet after the TCP handshake.\r\nNetwork defenders can create and implement additional signatures to detect differing TCP payload sizes and the\r\npacket’s respective size tracking sequences. The following Snort signature can be used to detect unmodified\r\nQuasar v1.3.0.0; however, it is unknown if this signature can be used to detect modified versions.\r\nalert tcp $EXTERNAL_NET :1024 -\u003e $HOME_NET any (msg:\"Non-Std TCP Server Traffic contains '|40 00 00\r\n00|' (Quasar RAT Initial Packet)\"; sid:10000; rev:1; flow:established,from_server; dsize:68; content:\"|40 00 00\r\n00|\"; depth:4; fast_pattern;)\r\nQuasar uses a TCP payload of 68 bytes at the beginning of each of its sessions. Quasar’s distinctive 68-byte TCP\r\npayload presents the best opportunity for network defenders to identify Quasar activity.\r\nIt is likely that the Quasar TCP payload server packet will originate from TCP port 80 or 443 to traverse network\r\nfirewalls and attempt to blend in with normal web browsing traffic. Network defenders may want to further limit\r\nthis Snort signature to only TCP ports 80 or 443.\r\nhttps://www.cisa.gov/news-events/analysis-reports/ar18-352a\r\nPage 8 of 10\n\nWhen reviewing alerts generated by this Snort signature, network defenders should look for server-to-client TCP\r\nPSH/ACK packets following the alert packet. True positive alerts will likely have a 4-byte tracking sequence equal\r\nto the size of the TCP payload minus 4 bytes, with what appears to be ciphertext in the remaining payload.\r\nNCCIC recommends applying this Snort signature to a network sensor located on an organization’s perimeter to\r\nlimit the false positives generated by internal organization traffic.\r\nSignature 2: IP Lookup User-Agent String, HyperText Transfer Protocol Header Host, and HyperText\r\nTransfer Protocol Header URI\r\nalert tcp $HOME_NET any -\u003e $EXTERNAL_NET $HTTP_PORTS (msg:\"HTTP Client Header contains 'Host|3a\r\n20|ip-api com', URI '/json/' (Quasar RAT)\"; sid:10002; rev:1; flow:established,to_server; content:\"Host|3a 20|ip-api|2e|com|0d 0a|\"; http_header; fast_pattern:only; content:\"User-Agent|3a 20|Mozilla/5.0 (Windows NT 6.3|3b|\r\nrv|3a|48.0) Gecko/20100101 Firefox/48.0|0d 0a|\"; http_header; content:\"/json/\"; http_uri; depth:6; urilen:6,norm;\r\npriority:2;)\r\nThis Snort signature alerts on the WAN IP lookup initiated by the Quasar client. The User-Agent string, Hypertext\r\nTransfer Protocol (HTTP) header host, and HTTP header URI values are set by the server component when the\r\nclient is built. The server component is configured with these values at compile time. The User-Agent string\r\nmimics Windows 8.1 running Firefox 48, both of which are considerably dated. It is possible to see this User-Agent string used legitimately; however, organizations with information technology baselines should know if this\r\nUser-Agent string legitimately exists in their network environment.\r\nSignature 3: Hidden HTTP Request User-Agent String and Time-to-Live\r\nalert tcp $HOME_NET any -\u003e $EXTERNAL_NET $HTTP_PORTS (msg:\"HTTP Client Header contains 'User-Agent|3a 20|Mozilla/5.0 (Macintosh|3b| Intel Mac OS X 10_9_3) AppleWebKit/537.75.14 (KHTML, like Gecko)\r\nVersion/7.0.3 Safari/7046A194A', TTL 65-128 (Quasar RAT)\"; sid:10001; rev:1; flow:established,to_server;\r\ncontent:\"User-Agent|3a 20|Mozilla/5.0 (Macintosh|3b| Intel Mac OS X 10_9_3) AppleWebKit/537.75.14\r\n(KHTML, like Gecko) Version/7.0.3 Safari/7046A194A|0d 0a|\"; http_header; fast_pattern:only; priority:2;)\r\nThis Snort signature alerts on a client-generated hidden HTTP request. The Quasar user can direct the target host\r\nto visit a URL and retrieve the content. If the request is set to “hidden,” the client uses this User-Agent string to\r\nmimic Mac OS X 10.9.3 and Safari 7. Mac OS X 10.9.3 and Safari 7 are not only dated, but also do not match the\r\nOS on which Quasar operates (i.e., Windows). When reviewing alerts NCCIC recommends looking for packets\r\nwith a TTL between 65 and 128.\r\nReferences\r\nFireEye blog on new tools used by an APT group\r\nPalo Alto Networks Unit 42 blog on Quasar\r\nRevisions\r\nhttps://www.cisa.gov/news-events/analysis-reports/ar18-352a\r\nPage 9 of 10\n\nDecember 18, 2018: Initial version|December 21, 2018: Updated signatures\r\nSource: https://www.cisa.gov/news-events/analysis-reports/ar18-352a\r\nhttps://www.cisa.gov/news-events/analysis-reports/ar18-352a\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.cisa.gov/news-events/analysis-reports/ar18-352a"
	],
	"report_names": [
		"ar18-352a"
	],
	"threat_actors": [],
	"ts_created_at": 1775434106,
	"ts_updated_at": 1775791317,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/0cfc49eacece7037e8bad568e7ea993816fb2b62.pdf",
		"text": "https://archive.orkl.eu/0cfc49eacece7037e8bad568e7ea993816fb2b62.txt",
		"img": "https://archive.orkl.eu/0cfc49eacece7037e8bad568e7ea993816fb2b62.jpg"
	}
}