The SolarWinds Orion backdoor, known as SUNBURST or Solorigate,
has been analyzed by numerous experts from Microsoft, FireEye and several anti-virus vendors.
However, we’ve noticed that many of the published reports are either lacking or incorrect
in how they describe the steps involved when a client gets targeted by the threat actors.
We have therefore decided to publish this writeup, which is based on the analysis we did of the SolarWinds backdoor when creating our
avsvmcloud.com DNS queries are not DGA related
The DNS communication between the backdoored SolarWinds Orion clients and the authoritative name server
for avsvmcloud.com is not caused by a Domain Generation Algorithm (DGA), it’s actually a fully functional two-way communication C2 channel.
The clients encode information, such as the internal AD domain and installed security applications into the DNS queries
and the DNS responses from the name server are used to instruct the clients to continue beaconing, stop beaconing or to target a client by proceeding to what we call
Stage 2 operation. Thus, the authoritative name server for avsvmcloud.com was actually the C2 server for Stage 1 and 2 operation of the SolarWinds backdoor.
Image: SolarWinds Backdoor State Diagram
Command: Continue Beaconing
The default response from the name server is the “Continue Beaconing” command, which indicates that the threat actors have not yet decided if the SolarWinds client is of interest for further activity.
Receiving a DNS A record in any of the following net ranges instructs the SolarWinds backdoor to continue beaconing:
In “Stage 1” operation the SUNBURST/Solorigate client starts out in the “New” mode where it exfiltrates the internal AD domain name.
The AD domain data is often split into multiple DNS queries to reduce the length of each DNS query.
The client later proceeds to the “Append” mode when the full AD domain has been exfiltrated.
In “Append” mode the client transmits a list of installed or running security applications to the DNS C2 server,
as we have described in our Extracting Security Products from SUNBURST DNS Beacons blog post.
The client remains in Append mode until it gets either terminated or targeted.
Note: It is also possible to reset a client back to the “New” mode with a so-called “Ipx” command, but that is out of scope for this blog post.
Command: Stop Beaconing
The stop beaconing command terminates the DNS beaconing, so that the client no longer retrieves any commands from the C2 server.
The C2 communication is stopped after receiving a DNS DNS A or AAAA record in any of the following ranges:
- fc00:: – fe00::
- fec0:: – ffc0::
Command: Target Client
A SUNBURST/Solorigate client that has been “targeted” will change a flag called rec.dnssec
in the source code from false to true.
We call this flag the “Stage 2” flag, which must be set in order for the client to accept a CNAME record and proceed to Stage 3.
Symantec refer to the Stage 2 flag as
“a bit flag representing whether the previous DNS response successfully contained partial or full instructions to start the secondary HTTP communication channel”.
A DNS A record in any of the following three IP ranges can be used to set the “Stage 2” flag:
The state of the Stage 2 flag is actually signaled in the avsvmcloud.com DNS queries,
which is how we managed to
identify the AD domains of 23 targeted organizations
just by analyzing SUNBURST DNS queries.
Stage 2 DNS Request Structure
The structure of the SUNBURST/Solorigate DNS queries in Stage 1 is pretty well described by
so we will not cover those in this blog post.
Instead we will focus specifically on the structure of the DNS queries transmitted in Stage 2 operation,
where the clients request a CNAME record from the name server.
As we have
explained previously the exfiltrated data gets base32 encoded,
using the custom alphabet “rq3gsalt6u1iyfzop572d49bnx8cvmkewhj”,
in order to ensure that only valid domain name characters are used in the DNS beacons.
The structure of the Stage 2 request, before it gets base32 encoded and appended as an avsvmcloud.com subdomain, looks like this:
|XOR Key||8 bits||A value between 0x80 and 0xff used to XOR encrypt the rest of the data.|
Client ID encrypted using a 16 bit rotating XOR key from
|Packet Type||4 bits||A value of 0x1, could in theory be 0x2 but that’s very unlikely.|
|Timestamp||19 bits||Number of 30 minute periods since start of 2010 (UTC).|
|Stage 2 Flag||1 bit||A flag set to “1” in Stage 2 operation, otherwise “0”.|
Image: Stage 2 beacon structure of the SolarWinds backdoor
The DNS responses from the name server not only controls how the SolarWinds backdoor should transition between the various stages,
it also controls for how long the backdoor should wait before sending the next DNS beacon.
The delay is assigned by AND-ing the last octet of the received IP address with bitmask 0x54.
The result from the AND operation is then used to select a sleep interval in the table below,
within which the client picks a random number of minutes to sleep.
|AND Result||Name||Sleep Interval|
|0x00||1 hour||30-120 minutes|
|0x04||4 hours||240-300 minutes|
|0x10||8 hours||480-600 minutes|
|0x14||1 day||1440-1560 minutes|
|0x40||3 days||4320-5760 minutes|
|0x44||1 week||10020-10140 minutes|
|0x50||2 weeks||20100-20220 minutes|
|0x54||1 month||43140-43260 minutes|
An exception to the table above is clients that have entered Stage 2, which will only wait one to three minutes before requesting a CNAME.
Example DNS C2 for a Non-Targeted Client
Below is an example of DNS queries and responses from a SUNBURST/Solorigate client that wasn’t targeted by the threat actors.
These particular queries and responses come from a
on SolarWinds’ community forum.
2020-07-04 00:03 UTC
Query: if9prvp9o36mhihw2hrs260g12eu1 ⇒ AD domain “omeros.local”
Response: 188.8.131.52 ⇒ sleep 1h, then Continue
2020-07-04 01:08 UTC
Query: hnhb3v1b37dvv09icg0edp0 ⇒ Carbon Black is running
Response: 184.108.40.206 ⇒ sleep 1 day, then Continue
2020-07-05 01:15 UTC
Query: ea99hr2sfen95nkjlc5g ⇒ Nothing new to report
Response: 220.127.116.11 ⇒ sleep 1 day, then Continue
2020-07-06 02:42 UTC
Query: 707gigk9vbc923hf27fe ⇒ Nothing new to report
Response: 18.104.22.168 ⇒ sleep 1 day, then Continue
2020-07-07 03:52 UTC
Query: 6eivqct649pcg0g16ol4 ⇒ Nothing new to report
Response: 22.214.171.124 ⇒ Terminate DNS beacon
Note: Queried domain names in this list are subdomains of
Example DNS C2 for a Targeted Client
Disclaimer: We have very few DNS queries and responses for targeted victims,
hence the transactions below are improvised based on data from
Joe Słowik and
Please view these transactions as an example of what the communication might look like for a targeted victim rather than what
actually happened to this particular target.
2020-06-11 04:00 UTC
Query: r8stkst71ebqgj66ervisu10bdohu0gt ⇒ AD domain, part 1 “central.pima.g”
Response: Sleep 1h, then Continue
2020-06-11 05:00 UTC
Query: ulfmcf44qd58t9e82w ⇒ AD domain, part 2 “ov”
Response: Sleep 1h, then Continue
2020-06-11 06:00 UTC
Query: p50jllhvhmoti8mpbf6p2di ⇒ Nothing to report
Response: Sleep 8h, then Continue
2020-06-11 14:00 UTC
Query: (?) ⇒ Nothing new to report
Response: Sleep 8h, then Continue
2020-06-11 22:35 UTC
Query: j5uqlssr1hfqnn8hkf172mp ⇒ Nothing to report
Response: Target client for Stage 2 operation (1-3 minutes sleep)
2020-06-11 22:37 UTC
Query: 7sbvaemscs0mc925tb99 ⇒ Client in Stage 2 operation, requesting CNAME
Response: CNAME “deftsecurity.com” is Stage 3 HTTPS C2 server
Note: Queried domains in this list are subdomains of
We hope this blog post clears up any misunderstandings regarding the targeting process of the SolarWinds backdoor
and highlights the significance of the Stage 2 flag.
Go to Source of this post
Author Of this post: Erik Hjelmvik