.Between the twitter hack and SigRed, yesterday was a little sporty for us all. I spent the last day hunting for SigRed exploitation in the wild. My dataset is passive DNS, but more on that hunting in a bit. Checkpoint's write up is here for reference. Since this flaw has to do with SIG record processing, it greatly limits the search space to find exploitation.

If you run Microsoft DNS server in your organization (odds are you do), there are a couple of quick detections you can implement. The first is a suricata rule developed by Positive Technologies out of Russia looking for the fingerprints of the a PoC in the query. You can access the rule at their github here. This should detect any response with the exploit in it that is traversing your network regardless of whether you are running Microsoft AD or not.

If you are running Microsoft DNS, by turning on Analytical Logs, you can see requests and responses. This has the advantage of enabling a few DNS hunting techniques which you can read a few about here. Even if the exploit fails (or it succeeds) it appears the exploit SIG record is written to logs. It should be easy to spot as the exploit record is much larger than a normal SIG record.

Passive DNS, as you may know, relies on a sensor that logs all queries and responses and makes those available in a queryable database. Most usage involves finding the history of a domain in terms of IPs it uses, or to find hostnames associated with an IP. However, the sensor logs all queries and responses which make it easy (in theory) to search for "off-protocol" use of DNS. In order for SigRed to work, an attacker has to own a domain to create malicious SIG records and I've been hunting for such usage (unsuccessfully). It's possible to create an IP feed for people making malicious queries, but better to identify the malicious domains instead.

The important feature of passive DNS is that it keeps a historical record. I was interested to see if this attack was used in the wild before the report. One limitation of passive DNS is that it is limited by wear sensors exist and few enterprises, especially interesting ones that are more attractive to APT attacks (the more likely user of this before Checkpoint's report) likely do not have passive DNS sensors near their internal DNS servers and give that information openly. However, in the past I've been able to use passive DNS to rebuild all communications over years of threat actors using DNS exfiltration. This is why it is also important, even if you don't share DNS query logs, that you store this information over a long term

We're maybe a day or so before there is widespread exploitation (if history is any guide), make sure to employ the detections above and write in if you see this occurring in the wild.

--
John Bambenek
bambenek \at\ gmail /dot/ com
ThreatSTOP