Disney+ domain being sinkholed as DNS tunneling domain

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Disney+ domain being sinkholed as DNS tunneling domain

L2 Linker

This morning I starting noticing that my threat logs are filling up with

sinkhole actions for the following

Suspicious DNS Query (search-api-disney.svcs.dssott.co)

Suspicious DNS Query (dssott.com)

 

 

Threat Type
spyware
Threat Name
DNS Tunneling Domain
ID
Category
dns-security
Content Version
AppThreat-0-0
Severity
high
Repeat Count
1
File Name
 
URL
Suspicious DNS Query (search-api-disney.svcs.dssott.co)

 

To get the site working again I have added a DNS signature exception for thread-id 109001001

 

Is it possible to except certain domains rather than the entire threat-id?  I fear that I am excepting more than just the domains I'm interested in.

 

 

PCNSC, PCNSE, Cyber Force Defender
1 accepted solution

Accepted Solutions

Given that adding an exception to 109001001 would disable the signature altogether if you want to add temporary exceptions you can actually do that per-firewall using CLI commands:

 

Check the status of the domain verdict by the following command 
> show dns-proxy dns-signature cache | match abc.com
*.abc.com                         C2          109000001   86327       0

 

Change the status of the domain verdict to benign by the following command. Please note that you are adding this domain as a whitelist on your PaloAlto Firewall on the management plane. This entry will only be effective on your Firewall locally.
> debug dnsproxyd dns-signature response verdict <new verdict you want> fqdn <FQDN> ttl <Time to live> gtid <preferably higher number>

Example for abc.com
> debug dnsproxyd dns-signature response verdict Whitelist gtid 420000700 ttl 30758400 fqdn abc.com

 

You can confirm the domain is been changed to benign. The last number zero indicates the number of hit to this domain.   
> show dns-proxy dns-signature cache | match abc
*.abc.com                         White list  420000700   30758373       0  

 

You can also confirm from data plane
> debug dataplane show dns-cache print | match abc
abc.com, wildcard: yes, ttl: 0/331353/0, temp: 0, verdict benign, utid: 420000700

 

Remove entry from the dns-proxy dns-signature cache
> clear dns-proxy dns-signature cache fqdn abc.com

View solution in original post

4 REPLIES 4

L0 Member

I have the same issue, I tested @jlieberman 's hypothesis about opening too much. A little wiresharking and I can confirm the FQDN below, search-api-disney.svcs.dssott.com, IS used for delivering the Disney+ service. The domain is owned by Disney as well.

 

After adding an exception using threat-id 109001001 to the Anti-Spyware -> DNS Signatures -> Exceptions, service to the site was restored, but I now bypass the DNS security completely it seems, note the test that is supposed to be blocked is now open as well:

 

Resolves correctly and service is restored:

 

fb@GREYSMB ~ % dig @8.8.8.8 search-api-disney.svcs.dssott.com +short

search-api-disney.bamgrid.com.

dgel2a5rs1evz.cloudfront.net.

143.204.35.80

143.204.35.34

143.204.35.113

143.204.35.125

 

Testing URL provided by Palo Alto- This should fail and point to sinkhole, but instead resolves.

fb@GREYSMB ~ % dig @8.8.8.8 test-dnstun.testpanw.com +short         

72.5.65.115

 

Normally the test URL looks like this and gets "sinkholed":

 

fb@GREYSMB ~ % dig @8.8.8.8 test-dnstun.testpanw.com +short

sinkhole.paloaltonetworks.com.

 

Faulty Rule catching the legitimate domain FQDN:

 

fb@GREYSMB ~ % dig @8.8.8.8 search-api-disney.svcs.dssott.com +short

sinkhole.paloaltonetworks.com.

 

This was caused by domain dssott[.]com being marked malicious.

The issue was resolved on 5/3, and should no longer be observed.

Given that adding an exception to 109001001 would disable the signature altogether if you want to add temporary exceptions you can actually do that per-firewall using CLI commands:

 

Check the status of the domain verdict by the following command 
> show dns-proxy dns-signature cache | match abc.com
*.abc.com                         C2          109000001   86327       0

 

Change the status of the domain verdict to benign by the following command. Please note that you are adding this domain as a whitelist on your PaloAlto Firewall on the management plane. This entry will only be effective on your Firewall locally.
> debug dnsproxyd dns-signature response verdict <new verdict you want> fqdn <FQDN> ttl <Time to live> gtid <preferably higher number>

Example for abc.com
> debug dnsproxyd dns-signature response verdict Whitelist gtid 420000700 ttl 30758400 fqdn abc.com

 

You can confirm the domain is been changed to benign. The last number zero indicates the number of hit to this domain.   
> show dns-proxy dns-signature cache | match abc
*.abc.com                         White list  420000700   30758373       0  

 

You can also confirm from data plane
> debug dataplane show dns-cache print | match abc
abc.com, wildcard: yes, ttl: 0/331353/0, temp: 0, verdict benign, utid: 420000700

 

Remove entry from the dns-proxy dns-signature cache
> clear dns-proxy dns-signature cache fqdn abc.com

I can confirm what @mivaldi has said.  After removing the exception, traffic to the domain is no longer being flagged.

PCNSC, PCNSE, Cyber Force Defender
  • 1 accepted solution
  • 5934 Views
  • 4 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!