{"id":309,"date":"2025-06-28T22:13:33","date_gmt":"2025-06-28T22:13:33","guid":{"rendered":"https:\/\/epbrtcybersecurityportfolio.xyz\/?p=309"},"modified":"2025-06-28T22:13:33","modified_gmt":"2025-06-28T22:13:33","slug":"dns","status":"publish","type":"post","link":"https:\/\/epbrtcybersecurityportfolio.xyz\/?p=309","title":{"rendered":"DNS"},"content":{"rendered":"\n

Exercise 1: <\/strong><\/p>\n\n\n\n

Description:<\/strong> There is a high volume of activity between 192.168.11.162 and 192.168.11.101 using UDP port 53. Can you explain what this is? Is the attack successful?<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

The first packet is a DNS query for the A record (or IPv4 address) of the domain www.evilname.com.<\/p>\n\n\n\n

This query is followed by several DNS responses which is very suspicious as normally one query is followed by one dns response packet. The response should match the query ID so that the client can match it to their request.<\/p>\n\n\n\n

We see that the transaction ID for our DNS query is 0x2870<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

The DNS response matching this ID is packet 118:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

The question is: what are these other 100 DNS response packets? DNS response packet number 118 was sent from the same MAC address that was listed as the receiver in the original DNS query. In contrast, the other 100 response packets came from a different MAC address. This looks like a potential DNS cache poisoning attack as multiple spoofed DNS responses begin arriving from 192.168.11.101 with a different mac address: 5a:92:eb:81:00:00. These packets also appear to respond to the www.evilname.com<\/a> query, but their transaction ids do not match the original query. They start at 0x0001 and increase incrementally.<\/p>\n\n\n\n

This behavior indicates that the attacker was attempting to guess the correct transaction id before the legitimate dns response arrived. This type of brute-force guessing is typical in dns cache poisoning attacks. In this case, the attack failed because the real server responded with the correct transaction id before the spoofed responses could match it.<\/p>\n\n\n\n

Exercise 2:<\/strong><\/p>\n\n\n\n

Investigate dns packet behavior by identifying anomalies or unexpected response codes in the packet capture file dns.pcap<\/code>.<\/strong><\/p>\n\n\n\n

Filter 1: identify dns queries that contain more than one question, which is considered abnormal. Craft a filter to detect packets with multiple dns queries in a single request.<\/strong><\/p>\n\n\n\n

I used tcpdump with berkeley packet filters to inspect specific fields in the dns header, particularly those found at udp offsets 10 and 11, where dns flags and return codes are located. I created a filter that looks for udp traffic on port 53 (dns), verifies the packet is a query (not a response), and checks that the number of questions is greater than one:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

We find one packet with two questions contained in a DNS query.<\/p>\n\n\n\n

Filter 2: detect dns responses with non-zero return codes by using both tcpdump and tshark. a non-zero return code in a dns response can indicate issues like a name resolution failure (e.g., nxdomain) or other errors, and is often worth investigating.<\/strong><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Exercise 3<\/strong><\/p>\n\n\n\n

Write a custom snort rule to detect dns queries targeting the domain “amazon.com”. The goal is to identify these queries by using both the content keyword to match the domain name and the byte_test operator to check for a valid query structure.<\/strong><\/p>\n\n\n\n

To get started with this custom rule, we know that Snort 3 has a dns service header already defined. Therefore, we can start with something like “alert dns ()”<\/p>\n\n\n\n

Now, we can think on how to properly add a content option to detect dns queries for the domain “amazon.com”. Instead of searching for the plain-text domain name, i had to account for how dns encodes names\u2014using length markers and sometimes compression techniques to make the query as small as possible. I began with a simple content match and gradually refined it to target the specific portion of the dns payload. I also used the pipe symbols to include raw byte values, ensuring my content match aligned with the encoded format of the dns query.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Let’s test this rule:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

The rules triggers but we see that some of these packets are dns responses that need to be filtered out. In order to do this, I used the byte_test keyword in snort to determine whether a dns packet is a query or a response. The query\/response (qr) flag is found in byte offset 2 of the dns header. Specifically, the qr bit is the highest bit in that byte. To detect this bit, i needed to use byte_test in combination with a bitmask (0x80) to evaluate whether the qr bit was set.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Let’s test it to make sure that this updated alert filters out the DNS responses when triggered:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

It did. The custom rule is now complete.









<\/p>\n\n\n\n

<\/p>\n","protected":false},"excerpt":{"rendered":"

Exercise 1: Description: There is a high volume of activity between 192.168.11.162 and 192.168.11.101 using UDP port 53. Can you explain what this is? Is the attack successful? The first packet is a DNS query for the A record (or IPv4 address) of the domain www.evilname.com. This query is followed by several DNS responses which […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-309","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=\/wp\/v2\/posts\/309","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=309"}],"version-history":[{"count":5,"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=\/wp\/v2\/posts\/309\/revisions"}],"predecessor-version":[{"id":334,"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=\/wp\/v2\/posts\/309\/revisions\/334"}],"wp:attachment":[{"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=309"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=309"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/epbrtcybersecurityportfolio.xyz\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=309"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}