Starting this morning (6:20AM CST), we are seeing threat notifications of suspicious dns requsts going to a group of domains that have been named in the Solarwinds Sunburst hack.
We've been trying to backtrack these all day. Our internal dns servers tell us that the requests are coming from the management interfaces of our HA palo alto firewalls. Palo Alto support tells us the firewalls are doing this to double check requests made by an internal machine. I've enabled dns logging and gone through those logs repeatedly, and the only requests are from the firewalls themselves.
This feels like something that changed with the update we downloaded at 5:30am this morning. Anyone else seeing suspicious dns queries that just started occuring today, especially for these domains?
There was a malicious update to SolarWinds’ Orion platform blamed for global hacks.
It has been reported In a statement, "SolarWinds said it had just discovered its systems experienced, “a highly sophisticated, manual supply chain attack on Orion software builds for versions 2019.4 through 2020.2.1, released between March and June.
“We have been advised this attack was likely conducted by an outside nation-state and intended to be a narrow, extremely targeted, and manually executed attack, as opposed to a broad, system-wide attack.” Administrators are urged to upgrade to Orion Platform version 2020.2.1 HF 1 (Hot Fix). A follow-up Hot Fix will be released Tuesday.”
Now Unit42 has released the blog https://unit42.paloaltonetworks.com/fireeye-solarstorm-sunburst/
All related coverages for SolarStorm and SUNBURST are covered on this Unit42 blog as of 15 Dec 2020.
Yes, thank you. We have followed all the mitigation advice.
The issue is that we are seeing our firewall management interface IPs requesting DNS for those malicious domains, but we cannot find a requesting device asking for them in the first place.
Just wondering if anyone else has seen the same behavior.
And we have a solution. We built a blacklist rule for the domains in question. The dns queries ARE from the firewall, it is confirming the IP addresses of those URL objects every few minutes.
Thanks Palo Alto support.
We are seeing the same behavior. We have a support ticket open with Palo Alto as to why all of the sudden the PA's management interfaces are making these DNS queries causing our security monitoring tools to alert us. Is this an official response as to why the Palo Alto devices are making these DNS queries?
In case you have created an address object( FQDN) on PAN and intended to use it as blacklist, in that case the PAN management interface will try to resolve it and you will see in logs.
I hope this helps.
As @hisingh indicates, this typically happens when IoC domains are incorrectly being configured as FQDN Address Objects and used in the Destination Address in Security Policies. (There is another possibility which is related to the reporting engine picking up blocked websites or blocked domains to populate IP addresses in pre-defined threat reports).
This will cause the firewall to attempt DNS resolution on the FQDN Address Object, and populate an IP Address for Security Policy match. If the firewall's own DNS traffic is inspected by the firewall, it will trigger the associated Anti-spyware DNS signatures.
Using IoC domains in FQDN Address Objects is incorrect, or simply offers limited protection, since the resolved-ip for the domain from the firewall can be completely different than the resolved-ip from a host for the same domain.
The correct way to block IoC domains is to block them using Anti-spyware DNS. (If you instead did it on a Custom URL profile, you would only be protecting from HTTP based connections. Always keep in mind, when you talk IoC domains, you talk DNS traffic, not HTTP).
To populate custom entries into Anti-spyware DNS you need an EDL of type 'Domain List', pulling in a text file with the list of domains from a web-server. Make sure to set the new EDL of type 'Domain List' to a sinkhole or block action in the DNS Policies tab of the Anti-Spyware profile.
If you want to double-up for HTTP based traffic, that's fine and recommended, and the source text file with the list of domains used for the EDL of type 'Domain List' (i.e named 'ioc-domains-dns') can be repurposed on a separate EDL of type 'URL List' (i.e. named 'ioc-domains-url'), and *also* set it to block in the URL Filtering profile, or directly under the 'Service/URL Category' tab of a Security Policy with a configured Deny action.
And yes, you can triple-up by adding FQDN Address objects as a Destination Address in Security Policies, but just be aware of the hit-and-miss detection capability, and that DNS signatures sourced from the firewall will fire-up. You can find a way to except them by dedicating a Security Policy with the source IP of the firewall and no Anti-Spyware profile attached, or attached to an Anti-Spyware profile configured with specific Anti-Spyware DNS exceptions (the later being the best option since you can still detect other malicious DNS requests sourced from the firewall which may help detect the unlikely case of a compromised Firewall, but of course, not if the firewall is compromised *and* the threat actor is using the threat being excepted).
Furthermore, while you can create independent entries in a Custom URL FIltering profile, these can be used for URL Filtering or the Service/URL Category tab of a Security Policy but cannot be used to feed domains into the Anti-Spyware DNS profile. If you tried creating custom DNS Spyware signatures for the domains, these will be considered 'spyware' signatures and not 'spyware-dns' signatures, which will only allow you to configure a block action, (action 'sinkhole' is not configurable for custom DNS signatures). If you need to sinkhole, your only option with custom Domains is an EDL of type 'Domain List'. If blocking the DNS request is good enough, you can avoid having to host an external list, and you can instead create a custom Spyware signature for the domain. An example is available in this Tech Note (Page 20). If there are multiple domains to cover, they can be created using an OR in the custom signature definitions, or simply create one custom signature per domain.
After everything is configured, commit the configuration and test from a protected Host using the 'nslookup <domain>' command in a system terminal window.
Crikey, I didn't even realise! the only only reason you got 3 stars was because of a dodgy tracking pad on my laptop and me not checking before I hit post sir!
Apologies I did think that your answer was more than correct.
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!