What happens when a non-compliant DNS query comes?

[zbalkan]

My question is strictly related to the Z flag bit. AFAIK only 2 uses are documented by RFCs: Reserved bit as always 0 and DNSSEC OK for 0x0800 or something like that.

What happens when a request with a non-compliant Z flag comes to DNS server?

I am asking as this is a documented C2 usage for DNS traffic.

[ShreyasZare]

Thanks for asking. The Z in the datagram has 3 bits with 1 unused. The used ones are Authentic Data (AD) and Checking Disabled (CD). The DNSSEC OK (DO) flag is set in the EDNS flags.

If DO flag is not set then the Z part is ignored by the DNS server. When DO is set then it check for the CD flag which decided if the server should return validated response of raw response for the client to validate by itself. The AD flag is set in response when the answer is DNSSEC validated if DO flag was set in request.

The DNS server always sets the CD flag in requests to upstream along with the DO flag in the EDNS flags if DNSSEC validation is enabled.

[ShreyasZare]

I am not really sure how its being used for C2. The link you have does not explain anything about it.

The CD flag in request is quite common and a standard thing. Same with AD flag in response (AD in request is ignored). The 3rd bit is not used anywhere and not really sure how 1 bit of flag will be useful for C2.

These flags are not end-to-end either, so a client setting these flags wont reach the actual name servers since the request will be processed by some DNS server on the network which will make an independent outbound request of its own.

Blocking requests just based on Z will be really breaking DNS IMO.

[ShreyasZare]

Just to add, its also not clear which bit of the 3 bits is being used by that malware for signaling. Also not clear is how that flag reaches their c2 name servers.

[zbalkan]

Hi @ShreyasZare,

I'd like to reference a very recent article that triggered this discussion actually. I have read about this topic in Suricata articles some time ago. This time it is a more generic one.

First is the three reserved “Z” bits in the DNS header. According to RFC 1035, these bits “must be zero” in all queries and responses. As a result, most security middleboxes and DNS servers ignore them completely. In other words, they “should” be 0, but can be any value between 0 and 7 inclusive without anyone or anything batting an eye.
In the case of the original technique the author proposes repurposing the Z-value as an End-of-Stream (EOS) marker. So when transmitting a large payload that must be fragmented across multiple DNS packets, all packets in the stream will have Z set to 0, whereas the final packet of the message will have the Z set to 1.
However as mentioned above in the SUNBURST example, any semantic meaning can be assigned here. Attackers can use these three bits to communicate up to eight different values, once again allowing for the creation of a simple, but effective state machine. For example:
Z = 0: “Continue beaconing.”
Z = 1: “Switch to HTTPS C2.”
Z = 2: “Download new stage from A record IP.”
Z = 3: “Go dormant for 24 hours.”
etc.

So this is a very covert way of communication for malware and the attacker infrastructure. In this case, it may be feasible to block queries that contain Z flag values that are not defined in any RFCs. I am suggesting a whitelist approach but in the form of packet validation.

[ShreyasZare]

Thanks @zbalkan for the details. From what I understand, the malware is sending these DNS requests directly to its c2 name servers. In that case, these DNS requests wont be hitting the local DNS server so there is nothing that can be done at the local DNS level. If all the outbound DNS requests are hijacked to force using local DNS server, any value in Z will get dropped.

[zbalkan]

99%, the malware uses direct requests to the malware operator owned DNS servers. Very rarely they use, or forced to use the internal servers. The question was about that case when the DNS is allowed only from internal DNS to external ones. If you say that part will be dropped, then there's no need to discuss anything. It was about not becoming an accidental relay for that transaction.

Thanks for the clarification.