Malware Analysis / Artefact: GetSystemInfoResponse.cs · SHA-256 45bd354d3741…

QuasarRAT: message contracts, remote access and campaign boundaries

Static source review of the archived open C# codebase: protobuf messages, client/server separation, persistence and defensive observation points.

Scope: Archived Quasar upstream source and MITRE technique mapping; no campaign or unknown binary.
Method: Static source and architecture review; no malware obtained, built or executed.
Evidence: Archived upstream source file with locally checked hash.

Finding

Message contracts and capability boundaries are inspectable in source; forks and campaign-specific modifications remain out of scope.

No independent sample, runtime, C2 or campaign verification.

Analyst note

What the evidence actually supports.

Quasar demonstrates why code lineage and malicious intent are not the same thing. Claims are tied to the archived message class and describe capabilities without labelling every derivative binary as an active RAT operation.

Evidence anchorsource snapshot checked

Artefact: GetSystemInfoResponse.cs
SHA-256: 45bd354d3741d30708107aa98372e742f8716e6a4148b5463a3c2c2e7915579e
Revision: 9508779fc0e91afd03775fd3fcc766eb8fb3a393
Analysis basis: Archived upstream source file with locally checked hash.

Malware / Evidence Atlas

Client configuration → Host effect

The analysis path for this report. Every node shows what is supported, where detection can start and where the claim stops.

5flow nodes 3detection artefacts 3rule formats

Claim

Client configuration

The concrete configuration bounds which infrastructure and runtime claims apply.

Detection focus

Join configuration fields with assembly revision.

Bound to primary research

Config Surface

Configuration fingerprint

Review pivots derived from the report — not a live configuration or universal family indicator.

TransportTLS socket

core

Messagesprotobuf

core

Installationconfigurable

support

Plugin surfacecapability map

support

Detection Pack

Defensive artefacts

Source, validation and limits accompany every rule.

SourceOriginal derivation from the structure described in the report.ValidationCompiled with yara-python; synthetic truth table 3/3.LimitYARA indicates open-source lineage, not malicious intent or active C2.

YARAOpen rule

Defensive model

rule DotNet_RAT_Quasar_Project_Identifiers {
 meta:
  author = "Ruhrdigital Studio"
  scope = "project lineage indicator; dual-use caveat"
 strings:
  $client = "Quasar.Client" ascii wide
  $common = "Quasar.Common" ascii wide
  $messages = "Quasar.Common.Messages" ascii wide
  $config = "Quasar.Client.Config" ascii wide
 condition:
  uint16(0) == 0x5a4d and filesize < 25MB and 3 of them
}

SourceOriginal derivation from the reported behaviour chain.ValidationParsed by pySigma; synthetic truth table 3/3.LimitYARA indicates open-source lineage, not malicious intent or active C2.

SigmaOpen rule

Defensive model

title: QuasarRAT remote-shell sequence candidate
status: experimental
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    Image|endswith: '\\cmd.exe'
    ParentImage|contains:
      - '\\AppData\\'
      - '\\Temp\\'
    CommandLine|contains: '/c'
  condition: selection
falsepositives:
  - Legitimate administrative or software activity with the same isolated pattern
level: medium

SourceOriginal translation of the same evidence chain for Defender XDR.ValidationOffline structural review; no Kusto engine available.LimitYARA indicates open-source lineage, not malicious intent or active C2.

KQLOpen rule

Defensive model

DeviceProcessEvents
| where Timestamp > ago(30d) and FileName =~ "cmd.exe"
| where InitiatingProcessFolderPath has_any ("\\AppData\\", "\\Temp\\") and ProcessCommandLine has "/c"
| project Timestamp, DeviceName, ProcessCommandLine, InitiatingProcessSHA256

Scope, snapshot and evidence boundary

Archived Quasar upstream source and MITRE technique mapping; no campaign or unknown binary. The bounded question is: which architecture and behaviour claims does this specific evidence set support, and which remain attributable only to the source?

ARTIFACT MANIFEST

Files and checksums

quasar/Quasar.Common/Messages/GetSystemInfoResponse.cs: 45bd354d3741d30708107aa98372e742f8716e6a4148b5463a3c2c2e7915579e
Protobuf response contract for system information.

What is supported — and what is missing

Primary sources, statically inspectable code and runtime observations carry different evidentiary weight. The map keeps those layers separate; missing first-party observation is not replaced by plausibility.

FILE / EVIDENCE MAP

Evidence chain and open runtime gap

The map separates primary source, reproducible source snapshots and runtime evidence not collected here.

A file reference does not establish runtime behaviour. Recorded processing is not a new execution.

SourceToolDerivedEvidenceMissingVerified referenceRecordedUnresolved

Evidence

Traceable source with an explicit sample gap.

Primary source

Published analysis or pinned upstream snapshot.

Primary source → GetSystemInfoResponse.cstechnically cross-checked · Verified reference
File, commit and SHA-256 were pinned.

Related report section →

GetSystemInfoResponse.cs

Locally hash-bound source snapshot, read statically only.

File: quasar/Quasar.Common/Messages/GetSystemInfoResponse.cs
SHA-256: 45bd354d3741d30708107aa98372e742f8716e6a4148b5463a3c2c2e7915579e
Location: 1-13

Primary source → GetSystemInfoResponse.cstechnically cross-checked · Verified reference
File, commit and SHA-256 were pinned.
GetSystemInfoResponse.cs → No local malware sampleruntime unresolved · Unresolved
The review remains static or source-bound.

Related report section →

No local malware sample

No first-party runtime, C2 or campaign telemetry.

GetSystemInfoResponse.cs → No local malware sampleruntime unresolved · Unresolved
The review remains static or source-bound.

Related report section →

Limit: A published observation is not an independent reproduction.

Entry and delivery chain

QuasarRAT is an openly available remote-access codebase, not one immutable campaign hash. Distribution occurs outside the project and varies by actor. This report therefore starts with the inspectable client/server and message model rather than inventing a universal infection chain.

Architecture and data flow

Shared protobuf contracts define requests and responses for system information, processes, drives, files, registry, desktop and other functions. Separate client and server handlers implement them. This explicit typing enables structural network and memory analysis without establishing an active control connection.

Original code as architecture evidence

The short excerpt shows only the structure discussed in this chapter. It is not executed and does not contain a complete operational implementation.

csharpSmall protobuf contract for system informationAnalysis tool excerpt

quasar/Quasar.Common/Messages/GetSystemInfoResponse.cs · Lines 7-12

Show file hash

SHA-256 45bd354d3741d30708107aa98372e742f8716e6a4148b5463a3c2c2e7915579e

7    [ProtoContract]
8    public class GetSystemInfoResponse : IMessage
9    {
10        [ProtoMember(1)]
11        public List<Tuple<string, string>> SystemInfos { get; set; }
12    }

Read the code

Analysis resistance and persistence

MITRE documents Run-key/startup persistence and variants with additional evasion techniques. Such functionality can be changed or removed in forks. A namespace, certificate or class name is therefore meaningful only with protocol and host behaviour.

Capabilities, objective and impact

The codebase includes remote shell, file management, registry, process, desktop and credential capabilities. This capability list describes possible impact in the reviewed snapshot; it does not prove which function was used in a specific infection.

Telemetry plan and evidence chain

Defensive models should connect .NET/protobuf structure, persistent client installation, a long-lived outbound connection and subsequent sensitive actions. Forks reduce the value of string- or namespace-only rules; sequences remain stronger. A defensible investigation preserves process GUID and full ancestry, user and session, command line, signer and hash state, file and registry changes, DNS/connection destinations and follow-on access to sensitive data in one timeline. Temporal proximity is an evidence parameter, not mere visualization. Missing sensor coverage is marked per stage so that an unseen event is not falsely treated as an event that did not occur.

Detection engineering and countertesting

yamlDefensive model, not engine-validatedDefensive model

1title: QuasarRAT remote-shell sequence candidate
2status: experimental
3logsource:
4  product: windows
5  category: process_creation
6detection:
7  selection:
8    Image|endswith: '\\cmd.exe'
9    ParentImage|contains:
10      - '\\AppData\\'
11      - '\\Temp\\'
12    CommandLine|contains: '/c'
13  condition: selection
14falsepositives:
15  - Legitimate administrative or software activity with the same isolated pattern
16level: medium

Read the code

Alternative hypotheses and negative tests

Before assigning the family, each signal used by the model is tested independently against software deployment, administration tools, installers, browser or backup software and known internal scripts. At least one structural anchor and one temporally consistent behaviour chain must align. Open upstream code is architectural evidence, not attribution of a binary or actor. The snapshot is archived; forks can change protocol, persistence and capabilities. A negative countercheck rejects only the tested hypothesis; it is not a general all-clear.

Attribution and variant risk

Open upstream code is architectural evidence, not attribution of a binary or actor. The snapshot is archived; forks can change protocol, persistence and capabilities.

Final assessment

The review provides a defensible architecture and detection baseline for the named snapshot. It is not proof of current activity, complete variant coverage or a specific operator.

Findings at a glance

Protobuf contracts make client/server capability boundaries explicit.
Open source and a campaign-specific fork must be separated.
Capability proves possibility, not use in a specific incident.

Review limits

No independent sample, runtime, C2 or campaign verification.
Open upstream code is architectural evidence, not attribution of a binary or actor. The snapshot is archived; forks can change protocol, persistence and capabilities.
Defensive models were not validated with a target engine.

Context, not evidence

The Evidence Anchor at the start identifies the binary, file or revision actually used. These links provide context and reported observations; they do not substitute for local sample analysis.

Quasar archived upstream source ↗MITRE ATT&CK — QuasarRAT S0262 ↗

Final assessment

Conclusion

Conclusion: structure before signature

The greatest defensive value comes from connecting entry, internal architecture, persistence, impact and telemetry. Individual names, hashes or IOCs remain supporting evidence, not the conclusion.

Next steps

Test models against synthetic positives and legitimate negatives.
Rebind version and evidence snapshot with every update.
Extend runtime claims only after first-party, lawfully available telemetry.

Basis of this judgmentHigh for directly inspectable structure; limited for runtime and campaign claims not independently reproduced.
Archived Quasar upstream source and MITRE technique mapping; no campaign or unknown binary.

← All research audits

QuasarRAT: message contracts, remote access and campaign boundaries

Message contracts and capability boundaries are inspectable in source; forks and campaign-specific modifications remain out of scope.

What the evidence actually supports.

Client configuration → Host effect

Client configuration

TLS connection

Packet protocol

Capability module

Host effect

Configuration fingerprint

Defensive artefacts

Scope, snapshot and evidence boundary

Files and checksums

What is supported — and what is missing

Evidence chain and open runtime gap

Evidence

Entry and delivery chain

Architecture and data flow

Original code as architecture evidence

Analysis resistance and persistence

Capabilities, objective and impact

Telemetry plan and evidence chain

Detection engineering and countertesting

Alternative hypotheses and negative tests

Attribution and variant risk

Final assessment

Findings at a glance

Review limits

Context, not evidence

Conclusion

Conclusion: structure before signature

Next steps

Discuss your project.