Shulou(Shulou.com)06/03 Report--

This article introduces the knowledge of "how to find the victims of the back door of SUNBURST through pDNS". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Overview

Our SunburstDomainDecoder tool can now identify the affected users of the SUNBURST backdoor. We only need to provide the tool with passive DNS (pDNS) data for the avsvmcloud.com subdomain to identify whether the user has been infected by the attacker's SUNBURST.

If the company and organization's computer devices install SolarWinds Orion updates with SUBURST backdoors, the devices will send seemingly random DNS query requests to the avsvmcloud.com subdomain. Some of these DNS requests will contain the internal AD domain of the target device and will be encoded into the subdomain name.

Three operating stages of SUBURST back door

Most of the victims of the SUBURST backdoor are actually lucky because the attacker did not actually attack them. This means that most SUBURST backdoors never perform the first stage of the infection process. Nevertheless, the attacker will execute some target users to the second stage of the infection. During this phase, the attacker uses the C2 coordinator and responds to a DNS A record pointing to the following range of IP addresses to conduct the next phase of infection and attack:

18.130.0.0/1699.79.0.0/16184.72.0.0/15

The SUNBURST backdoor that has entered the second infection phase will allow the CNAME record in the DNS response to be used as the new C2 domain.

We found that the SUNBURST backdoor actually uses a bit in the request to query the subdomain of the avsvmcloud.com site to mark that it has entered the second stage of infection and is accepting the new C2 domain in the CNAME record. This bit is called flag, ext, or dnssec in the back door of a malicious SUNBURST implantation, and this data can be extracted from DNS queries with encoded timestamps, such as those that indicate which security products are installed.

Detect DNS requests in the second phase of infection

Our SunburstDomainDecoder tool has now been updated and a "STAGE2" tag has been introduced in the output to mark the DNS query that contains this second-stage flag. This means that national organizations like CERTs, which specializes in security incident response coordination and customer notification, can now use SunburstDomainDecoder to identify and notify target SUNBURST victims who have entered the second phase of infection.

In the following example, we use Bambenek's uniq-hostnames.txt passive DNS data to run SunburstDomainDecoder and only show relevant content that contains "STAGE2":

SunburstDomainDecoder.exe < uniq-hostnames.txt | findstr STAGE222334A7227544B1E 2020-09-29T04Relay 00.0000000Z Magi STAGE2 5qbtj04rcbp3tiq8bo6tFC07EB59E028D3EE 2020-06-13T09Relay 00.0000000Z k5kcubuassl3alrf7gm33C327147876E6EA4 00.0000000Z k5kcubuassl3alrf7gm33C327147876E6EA4 00.0000000Z STAGE2

Most of the above subdomains have been recorded in the Indicator_Release_NBIs.csv file provided by FireEye, which contains CNAME pointers to other SUNBURST C2 domain names, such as freescanonline [.] com, deftsecurity [.] com and thedoccloud [.] com, etc., but the first domain name (GUID 22334A7227544B1E) does not belong to FireEye's intrusion threat indicator data.

By analyzing other passive DNS resources, such as Rohit Bansal's passive DNS dump on pastebin, we will be able to find more STAGE2 domains and guid values.

Curl-s https://pastebin.com/raw/6EDgCKxd | SunburstDomainDecoder.exe | findstr STAGE2E258332529826721 2020-07-18T05DV 00.0000000Z findstr STAGE2E258332529826721 2020-07-18T05GV 00.0000000Z findstr STAGE2E258332529826721 00.0000000Z 7sbvaemscs0mc925tb99F90BDDB47E495629 00.0000000Z 7sbvaemscs0mc925tb99F90BDDB47E495629 00.0000000Z 7sbvaemscs0mc925tb99F90BDDB47E495629 00.0000000Z 7sbvaemscs0mc925tb99F90BDDB47E495629 00.0000000Z STAGE2 gq1h856599gqh638acqnDB7DE5B93573A3F7 2020-06-20T02GradeStagE2 ihvpgv9psvq02ffo77etDB7DE5B93573A3F7 2020-06-20T02GradeStagE2 ihvpgv9psvq02ffo77et3C327147876E6EA4 2020-06-20T02GradeStagE2 mhdosoksaccf9sni9icp

After deleting the existing fields and several bogus fields in FireEye's IoC file, we get the following FQDN requested by the SUNBURST backdoor in STAGE2:

1dbecfd99ku6fi2e5fjb.appsync-api.us-east-1.avsvmcloud.com4n4vte5gmor7j9lpegsf.appsync-api.eu-west-1.avsvmcloud.com5qbtj04rcbp3tiq8bo6t.appsync-api.us-east-1.avsvmcloud.com

Companies and organizations that have access to more passive DNS resources are expected to use SunburstDomainDecoder to identify more target SUNBURST victims that have reached the second phase.

This is the end of the content of "how to find the victims of the back door of SUNBURST through pDNS". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.