FYI:
[ 64] 00 00 0C 76 2D 62 6D 34 30 66 32 77 67 34 36 02 ...v-bm40f2wg46.
[ 80] 77 63 08 79 61 68 6F 6F 64 6E 73 03 6E 65 74 00 wc.yahoodns.net.
Hey there!
2 things:
-
the topic min length has been updated to be 5. We appreciate that feedback and are happy to make the configuration change!
-
Is there any chance you can post the full tcp payload of the packet which caused the FP?
This FP is somewhat interesting because in DNS over TCP the first two bytes represent the length of the packet excluding the two byte length field. The rules leverages byte_jump and the jump is made from the beginning of the tcp payload (so before the 2 byte length field) and then ensures there isn’t data after it. The “from_beginning” is critical to not alerting on standard DNS over TCP traffic, though appears to have failed in this case (strange).
In reviewing this rule, I’d classify it as low confidence for ZBot. In our telemetry it does seem to be hitting on a bunch of “Non-DNS” traffic over port 53, at least one of which was Gh0stRAT.
Thank you much! 20 here as well 
Thanks! That setting has also been modified down to 5.
Is there any chance you can post the full tcp payload of the packet which caused the FP?
Sadly no…sensitive network and all 
I have not been successful in replicating the alert by using nslookup to produce the tcp query as follows
I’m happy to accept details privately via support @ emergingthreats [dot] net or the feedback portal @ feedback.emergingthreats.net
Without the details, I’ll do a general review of the rule, assign some metadata, etc.
I’ll see what I can do on my end…thanks again.