There has been some questions on how to use this data and some of the other information out there so I wanted to post some notes to help. This data was specifically time-gated to not include much, if any, data after sunburst was discovered. This was intentional. Some other datasets include data from after discovery which includes some obviously fictional hostnames so I thought it important to point out some things about passive DNS and how it works with the intelligence implications therein.
There are two ways to collect passive DNS, you either collect cache misses from the resolver directly or you grab port 53 off the wire. The former you get more accurate results because you can trust its real, the latter you get more interesting results because you can see stupid DNS tricks.
In the present case, bad guy (as far as we can tell) did wildcard A records under appsync east/west 1/2. So if last week I did an nslookup for putinhasasmallpackage.appsync... it would resolve and give me an IP. The CNAME comes in because in the zone #BadGuy would put specific records up front corresponding to targets of interest and specific match wins in DNS. Everyone else would still get the wildcard.
So passive dns sensors log queries and responses (but have no idea if traffic ever happened). So if someone did query putinhasasmallpackage. There would be a response, it would be logged, and pdns would show it even though it was patent BS. Before the news broke, no one knew this was here so its unlikely there is much poisoning UNLESS the Russians (attribution I am increasingly confident of) pre-planned being discovered. They historically like seeding “ambiguity” in attribution of the attacker, it would be new and very forward thinking (but not outside the realm of possibility) to sow the seeds of ambiguity of the victims.
When dealing with a sophisticated adversary, single data-point conclusions are a dangerous business. Russian intelligence has honed the fine art of trolling and they love to rustle those jimmies. So I fell confident in saying this data is that any org with an internal hostname discovered with the decoder and uses SolarWinds Orion should start the IR process. For those that see their hostname in a CNAME record (only 2 so far) you were likely a more interesting target. That said, not being in these records is no proof that you are clean. Passive DNS is not 100% global visibility and the most interesting targets would never have their internal DNS queries visible to the outside world.
As an outside observer, I would caution anyone from concluding much more than there was beaconing (which is bad enough). If you are a responding org, look for any DNS queries with the avsvmcloud domain in your query logs or use the JSON file and netflow logs to look for IPs in the specific time window they were valid. But if you use Orion at the specified patch levels that were backdoored, you'll need to do IR regardless. Someone got a foothold and that needs to be dealt with. What attackers did from there cannot be discerned from this dataset and some of the speculation is about potential harm. Right now, we need to focus on the actuals instead of chasing ghosts.
So to everyone who has to clean up this mess, good luck, and hope you can at least enjoy some of your holidays. I hope this information is helpful and if I can provide further assistance please feel free to ask.