DNS Tunneling In The SolarWinds Supply Chain Attack

The aim of this post is to provide a very high-level illustration of the DNS Tunneling method used in the SolarWinds supply chain attack.

1. An Attacker compromises SolarWinds company and trojanizes a DLL that belongs to its software.

2. Some of the customers receive the malicious DLL as an update for the SolarWinds Orion software.

3. “Corporation XYZ” receives the malicious and digitally signed DLL via update.

4. SolarWinds Orion software loads the malicious DLL as a plugin.

5. Once activated, the DLL reads a local domain name “local.corp-xyz.com” (a fictious name).

6. The malware encrypts the local domain name and adds it to a long domain name.

7. The long domain name is queried with a DNS server (can be tapped by a passive DNS sensor).

8. The recursive DNS server is not authorized to resolve avsvmcloud[.]com, so it forwards the request.

9. An attacker-controlled authoritative DNS server resolves the request with a wildcard A record.

10. The Attacker checks the victim’s name, then adds a CNAME record for the victim’s domain name.

11. The new CNAME record resolves the long domain name into an IP of an HTTP-based C2 server.

12. The malicious DLL downloads and executes the 2nd stage malware (TearDrop, Cobalt Strike Beacon).

13. A Threat Researcher accesses the passive DNS (pDNS) records.

14. One of the long domain names from the pDNS records is decrypted back into “local.corp-xyz.com”.

15. The Researcher deducts that the decrypted local domain name belongs to “Corporation XYZ”.