Suspicious DNS Query - how to find source computer?

[_slv_]

Hi

Since I upgraded to 5.0.3 from 4.1.10 I started getting such entry in Treat log:

Suspicious DNS Query (Backdoor.rshot:app.pou.me) 4009473 spyware medium drop-all-packets 74

Suspicious DNS Query (Downloader.fik:encyklopedia.eduteka.pl) 4008620 spyware medium drop-all-packets 31

Suspicious DNS Query (generic:stor1173.uploaded.net) 4014899 spyware medium drop-all-packets 26

Bot: Torpig Phone Home DNS request 12657 spyware medium drop-all-packets 276

Suspicious DNS Query (generic:www.tns-counter.ru) 4000032 spyware medium drop-all-packets 40

It's pointing to my two DNS servers for my local networks. I'm almost sure that this isnt a problem with this servers because last week was Eastern Christmas and during this time I never got such traffic. When my users back to work its started again.

Some of user's computers are in the same Zone as this two DNS servers. How in this case catch sources of this traffic?

For other network I will enable strict Tread profile on allow DNS traffic rules, I hope that this will give me information about real sources of this dns requests.

With regards

Slawek

[BCH]

Have a look at the DNS servers' log files if available ? That should direct you to the client IPs requesting such hostnames.

[ericgearhart]

Having your DNS server logs forwarded to a centralized location such as a log collector appliance or SIEM, or having full packet captures to an appliance (or both!) are two things that are essential in my mind for being able to effectively research events like these.

Here are two suggested ways of doing this "on the cheap" (the only cost is hardware and time essentially)

For the log collector/SIEM, an open source solution I can recommended is ELSA: enterprise-log-search-and-archive - Enterprise log search and archive (ELSA) is an industrial-stren...

"ELSA is a centralized syslog framework built on Syslog-NG, MySQL, and Sphinx full-text search. It provides a fully asynchronous web-based query interface that normalizes logs and makes searching billions of them for arbitrary strings as easy as searching the web. It also includes tools for assigning permissions for viewing the logs as well as email based alerts, scheduled queries, and graphing."

For an open source full packet capture solution, I've read about openfpc: openfpc - Open Full Packet Capture - Google Project Hosting

"OpenFPC is a set of scripts that combine to provide a lightweight full-packet network traffic recorder & buffering tool. It's design goal is to allow non-expert users to deploy a distributed network traffic recorder on COTS hardware while integrating into existing alert and log tools."

[_slv_]

Hi

Thank you for your sugestion. For first step I will enable logs on my DNS serwers, if this doesnt help I will try to setup SIEM.

[BCH]

As for log collection or easier searches, you might want to try Splunk out (www.splunk.com), kinda easy to install and setup, with very straightforward searches (although the free version comes with a daily log limitation of 500MB ).

[UhMayYeah]

You can just enable the DNS signature PCAP for the spyware profile and view the PCAP clicking the PCAP icon in the threat logs.

P.S: Illustration performed on OS_5.0.x

Regards,

Ameya

[ericgearhart]

If the Palo Alto only saw the request from the DNS server out to the Internet and alerts on that traffic, wouldn't that still not provide enough info to track down the original client?

If you added a mirrored switch port of your LAN side network trwffic to a tap port on the PA, then the original client could be seen. Also if you segregated your DNS server from your clients into two separate VLANs and used the PA to route between them, you'd see the original traffic that way too.

Full packet capture / centralized logging is still the overall 'best practice' in my humble opinion

[HITSSEC]

We are dealing with this issue now and we may not have access to DNS logs and we have a distributed DNS structure with an internal root DNS.  The root dns server may only be forwarding a request drom one of our distributed dns servers.  What we are looking is creating FQDN based objects for the DNS entries identified by PA and then putting those objects in a rule to block non DNS traffic.  This will identify the probable comprimised hosts.

Phil

[_slv_]

>If the Palo Alto only saw the request from the DNS server out to the Internet and alerts on that traffic, wouldn't that still not provide enough info to track down the original client?

not, because klient and dns server are in the same security zone. That is my problem. Rest of my networks are separated, that one no.

I came up with idea: put on every policy from separated network security profile that will block such traffic. After that if I will have in logs warnings about thats mean that problem is from this one zone with DNS servers on it.

I also preparing for Splunk instalation. That could help me now and in the future.

Thank you for your help

[Sly_Cooper]

I ran into similar situation with conficker spyware. The option is to enable logging on the DNS server to find out the original client. That is usually not possible due to high volume of logs. The other option is to SPAN/mirror your DNS server port and configure TAP on PAN. I have this configuration running in my network and it provides you with the real client ip address.

[mikand]

What about creating a new VSYS on your PA device and attach 2 interfaces to it which you configure as VWIRE and then plug that between your DNS and the rest of the network?

Oh and in this VSYS configure it only for alterting to not disturb the flows (that is unless you wish to block the queries with the help of the PA).

[_slv_]

Mikand: I know that VWIRE is better (easier) than SPAN port on switch.

At the moment I have a lot of things to do and I haven't time for it.

I have PA200 and I'm not sure that I can create second VSYS, and I'm sure that I ran out of free Security zones (I have used 10 at the moment).

But if you can help me on priv (I 'm alsomst newbe in PAN) we can do it.

At the moment I isolated problem. This suspicius reguest comes from my WiFi networks, so its mean that from private users computers. Thats good for me

[lpham]

You'll have to enable dns debug file on your dns server to get the level of detail you need to find the sources of the dns requests.

Here's how; (Warning: Microsoft recommends only keeping dns debug captures enabled temporarily)

1. Login to server

2. Open dnsmgmt - (Administrative tools -> DNS)

3. Right Click on your server object and select properties

4. Select Debug Logging

5. Put check mark on;

     Packet Direction [Outgoing and Incoming]

     Packet Contents [ Queries/Transfer]

     Transfer Protocol [UDP/TCP]

     Packet type [Request/Response]

6. Choose where you want the debug file created and make sure you have enough space to hold the files.

7. Select OK

8. Done

Now just go into the threat log of Palo Alto, find the dns name ie. google then search [Ctrl+F] for that URL in the dns debug file . Make sure to only search for the URL without the suffix at the end. (example: google.com - only look for google as the dns debug format substitutes dots for a format like "(6)" .)

That is the quick and dirty way to find it. If you have hundreds of entries from multiple sources, you will need to create a script. I wrote a VB script for this very purpose to find Conficker infected hosts on my network. It's 100% accurate. If anyone wants a copy, reply back to me and I can post the code.

[networkadmin]

Just to say I found this thread really beneficial.  We only allow our AD servers to do outbound DNS queries and it never occurred to me that spyware signatures would check DNS traffic - enabled it and cleared the DNS server caches and sure enough had a ping for a nice piece of webwebgo crapware

[jkim2]

use the dns sinkhole feature in 6.0 this is what its meant for.

user makes dns request , dns server performs look up, palo alto picks this up via dns signature then returns sink hole ip . User then tries to connect to the sinkhole ip and its will get recorded in the traffic logs as such.

How to Configure DNS Sinkholing on PAN-OS 6.0