So I tried to search the web for answers but didn't find any.
Is there any way to trace back which exe file or application caused the computer to make a specific DNS query?
4
-
3You are mentioning "exe" in your question, I assume you are therefore referring to Windows OS? Possible answers may indeed greatly depend on the exact OS used. – WhiteWinterWolf May 9 '15 at 12:39
-
3From which standpoint? From the perspective of the DNS server? From the perspective of the local machine? – SEJPM May 9 '15 at 12:54
-
I'm afraid that would require you to replace the existing resolver with your own resolver that logs the calling process or the like - and assumes that the attacker did not include his own resolver as well. In the latter case you'd need to first find out which process accessed the NIC – Hagen von Eitzen May 9 '15 at 13:32
-
1If you mean historically - this happened already and you want to figure out who queried - then no, there's no way. – gowenfawr May 9 '15 at 13:57
-
Maybe you find something in the system's log about an application or service that was started shortly before the query was made. – ott-- May 9 '15 at 23:11
1
Any application can easily submit any DNS resolution request. There are numerous libraries available and programmers can choose to perform the resolutions whichever way they want. For example, in Python it's one line of code (maybe two)
import dns.resolver
answers = dns.resolver.query('dnspython.org', 'MX')
To link an actual application to the UDP (assuming it is using the default UDP protocol) "session" it used to send the request, is a rather hard task. There are tools available for different Operating Systems (for example HomeProject or Microsoft Network Monitor) which can help to that direction.
Keep in mind, that the resolution process takes roughly a few milliseconds (DNS is competing among the fastest protocols). The process of resolving a domain name in order to get the IP address it resolves to, is being delegated from the stub resolver (the "application" that needs the IP address for a corresponding domain name) to a Recursive DNS Server (aka RDNS). An example of such server is Google's Public DNS, at 8.8.8.8 and 8.8.4.4. Your ISP will most likely provide the IP addresses of the RDNS servers it operates to your home modem/router, which will send them to the devices connected to it (via DHCP for example).
Among other things RDNS servers will store a matching domain name to IP address pair in their internal cache memory for a certain amount of time (TTL, Time To Live). This means that if you perform a resolution request within that time frame, the RDNS server will not go down the recursive resolution process, but will reply with the matching IP address it already has in memory. Therefore, the stub resolver will get a response extremely fast. For example, this is the time it takes to perform a resolution:
The first time
;; Query time: 248 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
The second time
;; Query time: 40 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
What you are trying to do, is monitor which application opened a UDP socket on your system and listened to that socket for a response, for less than 3 seconds (the default timeout value for DNS). If you are not continuously monitoring both traffic and processes listening to specific ports, then as far as I know, there is no way to get the match. For future use, you will be able to match a process and a corresponding DNS resolution request, by looking at the ports used. For example, if application 1 opens port 7788 and you see a DNS request in the network traffic at the same time with source port equal to 7788 (destination will most likely be 53), then you have the application!
