Lee Kirkpatrick

Using RSA NetWitness to Detect C&C: WEASEL

Blog Post created by Lee Kirkpatrick Employee on Dec 6, 2019

I was doing some hunting through our lab traffic today and came across some strange looking traffic, it turned out to be Rui Ataide playing around with a new DNS C2. It is named WEASEL and can be found here: GitHub - facebookincubator/WEASEL: DNS covert channel implant for Red Teams. From this, we decided to put together this quick blog post to go over how the traffic looks in NetWitness Packets, therefore, this is in a slightly different format to my usual posts in this topic. We may at some point update this to a full post if needed.

 

 

NetWitness Packets Analysis

As this tool uses DNS for its communication, we first need to place our focus on DNS traffic, we can do this with a simple query like so, service=53 - from here, I like to open the SLD (Second Level Domain) meta key and look for suspicious sounding SLD's, or SLD's that are quite noisy. From the screenshot below, doh stands out as a good candidate:

 

It is also a good idea to do the same with TLD to see if anything suspect stands out. We blurred out the domain we were using in this instance, but the .ml TLD should stand out as suspect as it is free to register and commonly used for malicious purposes:

 

Upon drilling into the suspect SLD (sld='doh'), we can then open the Hostname Alias Record meta key to see how many unique values are associated with that SLD. This type of DNS activity requires uniqueness in the requests it makes in order for the DNS queries not to be resolved by the cache, and this is why you would have a large number of unique alias.host values to a single SLD when performing this type of activity using the DNS protocol. This is depicted nicely by the below screenshot:

You would also typically see a large number of these DNS requests over a small period of time, however, this would be entirely dependent on the C2 and the beaconing interval set. For the above, the time range was over ~12 hours:

 

 

This traffic could easily be detected by using the following logic in an application rule:

(alias.host regex'^[0-9a-vx-z-]{2,52}w{0,6}\.[0-9a-f]{2}\.[0-9a-f]{4}\.') && (dns.querytype = 'aaaa record')

 

For other tools, the following regex should work too, it may however need some adaptation for each specific tool:

^[0-9a-vx-z-]{2,52}w{0,6}\.[0-9a-f]{2}\.[0-9a-f]{4}\.

 

With that being said, altering the behavior of C2 communications like WEASEL can easily be done, which would then mean this application rule / regex would not trigger, and thus why it is always important to review the behaviors of protocols and not rely solely on signatures.

 

Conclusion

DNS C2's are becoming a more prevalent way to exfiltrate information in and out of a network. It is a transmission medium that often gets forgotten about as most would tie malicious communications with protocols such as HTTP or SSL and tend to only block those. DNS in nature can be very noisy, more so in this case as there is a finite amount of information you can transfer in AAAA records, and by design WEASEL also opted for shorter query names to evade detection, both these in conjunction increase even further the amount of DNS traffic being generated. Additionally, DNS requests are also cached for a period of time, they therefore need to be unique and names can't easily be reused, in order to avoid them being resolved by a cache instead of making it back to the attackers infrastructure. This inherent noisy behavior of DNS C2 makes it slightly easier to detect when the right tools are in place.

Outcomes