5. Mass Distribution and Victimology

Chapter 4 explained how SUNBURST encodes a victim’s identity into a DNS name and how the range of the DNS answer issues a go / stand-down / kill directive. This chapter is the evidence for that mechanism, and the answer to “who was actually beaconing.” It moves from the decompiled implant to three bodies of evidence examined for this book: the full installers that carried the backdoor through the legitimate update channel, the passive DNS record of the C2 fabric, and the decoded beacon observations recovered by reversing the DGA.

5.1 Act 4: the backdoor ships in full installers

The first weaponized release (Chapter 3) was a patch, the Hotfix-5 MSP that upgraded a clean 2019.4 install to the backdoored 9083 DLL. Distribution then moved to full installers, the kind a new customer downloads:

Both are full MSIs that ship already weaponized, and, as established in Chapter 4, the backdoor class inside them is byte-for-byte identical to the one in 9083. Same host process hash, same 12–14-day dormancy, same C2 logic; only the surrounding files and version stamps differ. There is one SUNBURST implementation across the three weaponized packages.

What the backdoor rode inside. It is worth seeing the scale of the carrier. The payload CAB in each installer was carved and its file list counted:

Two observations matter:

• The 2020.2 RTM → HF1 file lists are identical except seven version-stamped package names (two Core_*.apkg names 12394→12432, four PythonPrerequisite names with 3.7.3.58→.60, and one ServiceDirectory name), a genuinely small hotfix. Yet the embedded BusinessLayer DLL still carries the full SUNBURST implant. The backdoor was just another file in a routine ~1,930-file product update.
• The HF5 MSP is a minimal 41-file patch. That such a small, ordinary-looking patch is what converts a clean 2019.4 install into a backdoored one (the shared product code proof from Chapter 3) underlines the asymmetry: a tiny, legitimate-looking maintenance package was the delivery vehicle for the whole campaign’s first stage.

The implant hid in plain sight, inside a large, signed, expected product, not in some anomalous extra download.

5.2 The channel: a normal update from a trusted CDN

These four installers were not phished or side-loaded. They were pulled from the genuine SolarWinds content delivery network; archived download records contain URLs of the form hxxps://downloads.solarwinds[.]com/.../CoreInstaller.msi. Every step of the delivery was the normal step a customer expected: a signed installer, from the vendor’s own CDN, over the update channel they already trusted. That is the entire supply-chain thesis from Chapter 1, made concrete: there was nothing for the customer to catch at install time.

SolarWinds initially reported an upper bound of up to ~18,000 potentially affected customers based on downloads and later stressed that this included customers that did not install the update or whose servers could not contact C2. Even a confirmed installation would be the top of a funnel, not a hands-on compromise count (Chapter 1). The rest of this chapter examines the subset visible in the available DNS data.

5.3 The C2 fabric, seen in passive DNS

Chapter 4 left the C2 fabric as a mechanism. The dataset analyzed for this book captures the observed fabric: a passive DNS export of 500 A record resolutions for avsvmcloud[.]com (≈ Apr–Dec 2020). Parsed, it yields 445 unique IPs and 268 unique DGA beacon FQDNs. For example:

00all4hqt8ge8f4frl5k.appsync-api.eu-west-1.avsvmcloud.com
q7g7t7be3u1otao4ed1n60t12eu1.appsync-api.eu-west-1.avsvmcloud.com

The left-hand label is the DGA output from Chapter 4, a victim ID + time token + flags, encoded in scrambled base32. The actor’s authoritative infrastructure is visible too:

Hosting the name servers on AWS, with hostnames shaped like appsync-api.<region> (a real AWS service naming pattern), is part of the camouflage: to a casual look, the beacons resemble an application talking to an Amazon API endpoint.

5.4 The key finding: the A record is a directive, not a destination

This is where the passive DNS data directly confirms Chapter 4’s §4.5 claim. SUNBURST does not use the resolved A record as a real address to connect to; it reads the range the IP falls into as a command. Classifying all 445 observed IPs against the implant’s hardcoded nList ranges (the AddressFamilyEx switch from §4.5):

422 of 445 (94.8%) of the responses land inside the malware’s own signalling ranges. This is not coincidence; it is the operator’s name server answering each victim’s DGA query with an IP chosen for its range membership, to issue a directive. The 23 outliers are infrastructure and post-takeover sinkhole IPs, which fall in no signalling range.

The skew is real in the address set, but it is not a victim or target ratio. Unique response IPs are not unique hosts; range sizes and randomized control fields affect address diversity; and a NetBIOS range A record does not open HTTP C2 without a non-empty CNAME. The actual HTTP C2 destinations sit behind those CNAMEs and are not established by this classification based only on A records. The data proves that DNS was a control plane; it does not quantify how many organizations were promoted or stood down.

Killswitch preview. One range matters for Chapter 8: on 2020-12-15 the defenders repointed avsvmcloud[.]com to 20.140.0.1, which falls in 20.140.0.0/15, an ImpLink (stand-down) range. The global killswitch fed that directive to implants still resolving through the initial DNS path; it did not reach hosts already handed off to separate secondary C2.

5.5 Reversing the DGA: who was beaconing

Because the DGA is reversible by anyone who understands CryptoHelper (Chapter 4), the encoded labels can be turned back into victim IDs and, for the Phase-A registration records, into the victim’s AD domain name. The decoder used for this analysis has two modes:

• its default mode clusters beacons by their encoded userID;
• its --domains mode additionally reverses the Phase-A registration records (a second alphabet, a Caesar-+4 over rq3gsalt6u1iyfzop572d49bnx8cvmkewhj, with 0 marking ./_/-) and reassembles the AD domain per userID.

Run against the 268-FQDN capture, it recovers 147 distinct victim IDs and 11 named domains (e.g. nvidia.com, dsh.ca.gov, repsrv.com, fcmat.org, kk.dk, loves.com, vsp.com), several cross-validated by also appearing in the beacon set, all consistent with the community’s December-2020 decodes.

A larger capture. A separate VirusTotal passive DNS export contains 2,841 DGA FQDNs (~10× the first capture, and a near-superset: 255 of the 268 reappear). Decoded with the same method, it yields the main victimology figures used here:

• 2,841 FQDNs → 1,624 distinct beacon userIDs.
• --domains recovers 164 distinct AD domain strings (128 complete, 36 truncated; 54 cross-validated, with the same userID in both the registration and beacon sets).
• All 11 names from the smaller capture reappear (a decode fidelity check).

The recovered AD domains read like a cross-section of the global economy and government, and this yields 117 additional decoded AD domain / organization attributions in the observed beacon data versus the original 11 (decoded beaconing, not confirmed compromise, see the caveat below). A representative slice (org attribution from the recovered AD domain string):

• US government (federal / state / local): ad.faa.gov (FAA), fda.gov, sba.gov, gs.doi.net (Interior), pageaz.gov + sc.pima.gov (Arizona), dmv.state.nv (Nevada), vwc.state.va (Virginia), cityofno.com (New Orleans), capmetro.int (Austin transit).
• International public sector: mocsll.gov.om (Oman), nswhealth.net (NSW Health, AU), rbe.sk.ca (Saskatchewan), uncity.dk (UN City Copenhagen), skynet.halmstad (Sweden).
• Enterprise: amr.corp.intel (Intel), gvl.is.l-3com (L-3), gdc0.chevron (Chevron), int.lukoil-int (Lukoil), global.borgwarn (BorgWarner), intra.rakuten (Rakuten), levi.com, wiley.com, us.rwbaird.com (Baird), corp.svbank.co (SVB).
• Education / health / media: its.iastate.ed (Iowa State), insead.org (INSEAD), corp.athenaheal (Athenahealth), rai.com (Italian broadcaster), 2news.tv.

The decoder is disciplined about noise: clearly non-victim strings (canthack.this, casino.prv, jarvis.lab, cow.local, malformed-region rows) are excluded as researcher/sinkhole artifacts rather than counted as victims.

Two independent confirmations. A Validin DNS history export containing 1,825 hostnames is a near-subset of the VT capture: 1,782 of its 1,786 beacons already appear in the VT set, so it adds source diversity, not new victims (a different vendor’s telemetry reaching the same conclusion). And a hand-enriched, community-sourced pan-Nordic slice (45 beacon host IDs → ~28 named organizations across Denmark, Sweden, and Norway) names large enterprises and public bodies absent from the VT/Validin captures, Ericsson, Volvo Cars, Skanska, Norges Bank Investment Management, the Danish Tax Administration, and critical infrastructure utilities among them. (Being community-decoded rather than locally derived, it is cited like the CISA reporting; the same observed beacon caveat applies, and it does not revise the headline VT figures.)

5.6 What the numbers do and do not say

This is observed beacon victimology, and the caveat is load-bearing:

A passive DNS resolution is an observation of a beacon, not proof of hands-on compromise. The range-based A records are directives, not destinations. Truncated single-chunk records identify an organization but not the full domain. These figures are a floor on breadth and an upper bound on hands-on counts: they say “this many networks ran the backdoor and phoned the DGA,” not “this many were exploited.”

With that caveat, the analyzed dataset yields 1,624 beacon userIDs and 164 recovered domains (128 clean, 54 cross-validated), a meaningful, independently derived sample of the potentially affected population, but not the whole. It independently demonstrates broad beaconing and the DNS control mechanism, while leaving the promotion ratio unresolved. Public reporting establishes that only a much smaller subset received hands-on follow-on activity. Those selected victims, the ones that received a “proceed” CNAME and a second stage, are the subject of Chapter 6.

Sources & evidence

• Book reference: See the Appendix: Timeline, IOCs, and Artifact Map for installer hashes, the consolidated timeline, signalling ranges, and evidence provenance.
• Installers and manifests (locally verified): the four installer packages establish release order, compile timestamps, CAB file counts, the RTM→HF1 seven-filename delta, and the byte-for-byte identical backdoor across weaponized builds.
• Passive DNS: the 500-record capture supplies 445 unique IPs and 268 DGA FQDNs; the larger VirusTotal export supplies 2,841 FQDNs. The Validin history provides an independent cross-check.
• Victim decoding: a purpose-built implementation of SUNBURST’s reversible DGA recovered the victim IDs and domain strings reported in §5.5; a community-sourced pan-Nordic slice provides additional independently reported observations.
• Provenance: compile timestamps locally verified; victim names are decoded here from passive DNS and consistent with the community’s Dec-2020 decodes, but represent beaconing, not confirmed compromise.
• Public scale/context: SolarWinds’ investigative update explains that the early figure represented potentially affected downloads rather than customers confirmed hacked; Microsoft’s second-stage analysis documents the DNS-to-second-stage funnel.
• Forward references: the killswitch range → Chapter 8; the escalated victims and second-stage activity → Chapter 6.