This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
Failed to load latest commit information.
# # ______ ____ __ __ _____ # | __ | @ | \ | \ | || ___| (TM) # | _____|.------. .-----. .-----. _ -. .-.------. | |\ || \| ||___ | # | | | __ ||__ --'|__ --'| |\ Y /| _--__|_| |/ || || \_| | # |__| |____|_||______||______||_| \_/ |_______/|____/ |__|\__||_____| # # A tool to collect DNS records passively to aid Incident handling, Network Security Monitoring (NSM) and general digital forensics. PassiveDNS sniffs traffic from an interface or reads a pcap-file and outputs the DNS-server answers to a log file. PassiveDNS can cache/aggregate duplicate DNS answers in-memory, limiting the amount of data in the logfile without losing the essense in the DNS answer. Example output from version 1.0.0->Current in the log file (/var/log/passivedns.log): #timestamp||dns-client ||dns-server||RR class||Query||Query Type||Answer||TTL||Count 1322849924.408856||10.1.1.1||220.127.116.11||IN||upload.youtube.com.||A||18.104.22.168||46587||5 1322849924.408857||10.1.1.1||22.214.171.124||IN||upload.youtube.com.||A||126.96.36.199||420509||5 1322849924.408858||10.1.1.1||188.8.131.52||IN||www.adobe.com.||CNAME||www.wip4.adobe.com.||43200||8 1322849924.408859||10.1.1.1||184.108.40.206||IN||www.adobe.com.||A||220.127.116.11||43200||8 1322849924.408860||10.1.1.1||18.104.22.168||IN||i1.ytimg.com.||CNAME||ytimg.l.google.com.||43200||3 1322849924.408861||10.1.1.1||22.214.171.124||IN||clients1.google.com.||A||126.96.36.199||43200||2 PassiveDNS works on IPv4 and IPv6 traffic and parse DNS traffic over TCP and UDP. ** How can PassiveDNS be used: ** Typical usages: 1) Search for domain or IP history when working on an incident. Example: Company has malware talking to bad.twittertoday.com. At current time, the domain is resolving to say 188.8.131.52 You search your Flowdata and find the clients talking to that IP and remidate. You look at the Flowdata, and you discover that the date and time the clients first talked to that IP, and concludes that as the time of infection... But using PassiveDNS data, quering the domain, you get following history: FirstSeen | LastSeen | TYPE | TTL | Query | Answer ---------------------------------------------------------------------------- 2011-12-01 | 2011-12-11 | A | 60 | bad.twittertoday.com | 184.108.40.206 2011-12-11 | 2011-12-18 | A | 60 | bad.twittertoday.com | 127.0.0.1 2011-12-18 | 2012-01-14 | A | 60 | bad.twittertoday.com | 220.127.116.11 Going back and searching for 18.104.22.168 in your Flowdata, you find traffic back to the FirstSeen data, and you also see more clients initially infected (so you did not manage to remidate/check out all your clients in the first run by just looking at IP 22.214.171.124). Doing forensics on the the clients you missed in the first run, reveals that they have downloaded a different malware and deleted the initial one, that beeing the reason you did not see flows from them to 126.96.36.199. The new malware gives you new domains and IPs to go look for... 2) Say you have an indication of malicious C&C traffic going to an IP on port 80. The domain used by the alleged malware is supposed to be cc.twittertoday.com. Searching you Flowdata, reveals lots of clients talking to that IP, and you might think that the whole company is p0wned. A quick search in your PassiveDNS DB shows you that the IP in question is also hosting 300 + websites and you might even spot a website hosted on that IP that you are familiar with and that you know lots of people in the company would legit visit daily. Searching your PassiveDNS DB gives you no hits for the domain in question, hopefully meaning that you dont have that malware talking to that domain in your network. 3) You know that *.twittertoday.com are often used in malware and the subdomains change randomly. Many have rules for such domains in their IDS/IPS, sucking up unnecessary juice from the systems. Having a script pre-loaded with a list of regexp of domains and subdomains to watch for and giving you an alert when they hit will give you much better detection on threat based on domains. You can also do a whois for all new top domains seen, correlate the whois info with a list of know bad info, such as the name of the person or company that has registered the domain, telephone/fax numbers, address and so on, ending up with a score that might be high enough for triggering an alert to you :) Questions, suggestions, sugar or flame is always welcome :) I hope PassiveDNS gives you a new tool to fight malware and its herders... (c)2011-2020 - Edward Bjarte Fjellskål
No packages published