Running a “ipport:53” process search in Carbon Black has helped to locate hosts and/or processes performing an abnormal number of DNS queries, however recently I wanted to hunt processes generating punycode IDN DNS queries on a client network. Alerts were triggered by their SIEM, which was ingesting Microsoft Server DNS logs. The Sumo Logic alert was created using the following query (for reference):
_sourceCategory=Prod/*/DC/Windows/DNS | parse regex "^(?[1]?\d/[123]?\d/\d{4}) (?)$"
| replace (question_name, /^(\d+)/, "") as question_name
| replace (question_name, /(0)$/, "") as question_name
| replace (question_name, /(\d+)/, ".") as question_name
| where question_name matches /xn--/
| count by question_name, ip_address
Once a DNS query triggered an email alert, I pivoted into Carbon Black using the process search query: domain:xn--*
Double clicking on one of the results, we can see a ‘netconn’ to a punycode IDN that looks like LastPass.
If the punycode is converted to ASCII, we can special characters at the end of the domain:
While the illustration above/ is a false positive, it demonstrates the procedure for identifying and hunting the root cause/process that generated a punycode IDN query whereas DNS server log analysis only shows the source system that made the query. Alerting on punycode IDNs often uncovers phishing attempts and user access of malicious or foreign sites. If logs are not being ingested by a SIEM, Carbon Black watchlists could be used as an alternative.