Tuesday, April 2, 2019

Instrumenting OS for Per Process DNS Query Inspection



Background information

Last night at #SANS2019 I attended Jason Fosen’s talk on process hacker and it reminded me of something I forgot to finish several years ago. I’m finalizing and posting now (several years later). This work was originally done on a windows 8 system.
Years ago, really way too long ago, I wrote a post about how to use DNS query logs to create a daily delta report to identify anomalies and novel connections: https://pen-testing.sans.org/blog/2015/07/10/dns-anomaly-analysis-tips-did-you-put-a-new-cover-sheet-on-that-ddd-report/


What's Doing That?
One of the things that I saw during review of the data was a weird DNS request.


Weird unqualified DNS requests. The unqualified version would be followed by the same random string in the search domain of the computer. Usually one or two queries with qualification. Something like biuivlhobb, then biuivlhobb.montance, then biuivlhobb.montance.local, as an example.
I looked into it via some online searches, and it was pretty clearly Google Chrome doing the queries. But, that wasn’t confirmed. So I dug deeper. I started thinking about how I could see inside of a system that a specific process made a DNS query. The OS was handling the query on behalf of a process. So, how could I see which process asked the OS to make that query?
My inquiry lead me to discover that the windows method for making a DNS request is getaddrinfo. The application would use this system call to do the lookup. https://docs.microsoft.com/en-us/windows/desktop/api/ws2tcpip/nf-ws2tcpip-getaddrinfo

So, I lauched process monitor to attempt to review what was actually making the calls.
Process Monitor : https://technet.microsoft.com/en-us/sysinternals/bb896645.aspx






There were two potential files of interest:
               C:\Windows\System32\dnsrslvr.dll
               C:\Windows\System32\dnsapi.dll
              
But, Process Monitor didn't show the details of the actual calls, so looked into APIMonitor:
http://www.rohitab.com/apimonitor

I set the filter to just look at getaddrinfo and related requests in case I missed something.

Killed existing chrome, started again, was able to identify the getaddrinfo requests:


Cool! chrome.dll verified as the source!




1 comment:

  1. Great post. It was a good read about the soc operation. Here IARM Top Cyber Security Company in Chennai provides information security services to enterprises, small & large scale organizations, Manufacturers, finance, Retails, IT/ITES and so on.
    Information Security Company in Chennai
    Penetration Testing Company In Chennai
    Soc Services In India
    Cyber Attack Recovery Services In India
    SOC2 Auditing Company in chennai

    ReplyDelete