Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > Author: Marco Faggian

RSA NetWitness Platform

2 Posts authored by: Marco Faggian Employee

When performing network forensics, all protocols should be analysed, however, some tend to be more commonly abused than others; one of these being DNS. While not as flexible as say HTTP, it does flow through, and outside of networks a lot easier due to its configuration. This means that DNS can be utilised to encapsulate data that would be routed outside the network to an attacker-controlled name server allowing data exfiltration or the download of tools. In this post, I will cover how we can use NetWitness Network to analyse the DNS protocol effectively, to do so we will use a tool called DNS2TCP (https://github.com/alex-sector/dns2tcp) in our lab to generate some sample traffic.

 

DNS record types

The DNS standard defines more than 80 record types, but many of these are seldom used. The most common are:

  • A Record - used to map a host and domain name to the IP address (forward lookup)
  • PTR Record - used to map an IP address to host and domain name (reverse lookup)
  • MX Record - to return host and domain mapping for mail servers
  • CNAME Record - used to return an alias to other A or CNAME records
  • TXT Record - used to provide the ability to associate arbitrary text with a host or other name

 

In this post, we will focus on TXT records being used to encapsulate data. TXT records are typically utilised as the size of this field allows for larger amounts of data to be transferred in a single request compared to A, or AAAA records. This field is also legitimately used to provide SPF records, specify the domain owner, return the full name of the organization, as well as other similar uses.

 

How Does NetWitness Network Analyse DNS?

The DNS_verbose_lua parser is available from RSA Live, it extracts metadata of interest from the DNS protocol that can help a defender in the identification of anomalous DNS traffic. We suggest that you subscribe to this parser (and others), as they are updated regularly.

 

 

Which metadata can help with the analysis?

The following meta keys are particularly useful for identifying, and subsequently analysing the DNS protocol:

Meta KeyDescriptionIndexed by default
serviceThe protocol as identified by NetWitnessYes
alias.hostThe hostnames being resolvedYes
alias.ipThe IP address that the hostname resolves toYes
service.analysisMeta values surrounding the characteristics of the protocolYes
tldThe top-level domain extracted from the hostnameYes
sldContains the part of hostname directly below the top-level domain (second level domain)No
dns.resptextThe response for the DNS TXT recordNo
dns.querytypeThe human readable value for the DNS Query type performed in the requestNo
dns.responsetypeThe human readable value for the DNS Query type returned by the responseNo

 

You will notice from the table above that some of the meta keys are not indexed by default. The following entries would therefore need to be added to the Concentrators index file so that they can be used in investigations:

<key description="SLD" format="Text" level="IndexValues" name="sld" defaultAction="Closed" valueMax="500000" />
<key description="DNS Query Type" format="Text" level="IndexValues" name="dns.querytype" valueMax="100" />
<key description="DNS Response Type" format="Text" level="IndexValues" name="dns.responsetype" valueMax="100" />
<key description="DNS Response TXT" format="Text" level="IndexValues" name="dns.resptext" valueMax="500000" />

NOTE: Details regarding the Concentrator index, such as how it works, ensuring optimal performance, and how to add entries can be found here: https://community.rsa.com/docs/DOC-100556

 

DNS2TCP

DNS2TCP is a tool that encapsulates TCP sessions within the DNS protocol. On the server side, we configure the tool to listen on UDP port 53, as per the DNS standard, we also specify our domain, "dns2tcp.slbwyfqzxn.cloud", and the resources. Resources are a local or remote service listening for TCP connections - in the example below, I specify a resource named SSH for connections to port 22 on 127.0.0.1:

The client will act as a relay for a specific resource, SSH in our example, and will listen on the specified port (2222) and forward traffic from the local machine to the remote server via DNS TXT records:

Once the communication between the client and server has been established, we can then connect to the server using SSH that will be encapsulated in DNS:

 

NetWitness Network Analysis

Homing in on DNS traffic is incredibly easy with NetWitness, we merely need to look for DNS under the Service meta key, or execute the query "service = 53". To place a focal point on possibly encoded DNS TXT records, we can pivot on the meta values, "dns base36 txt record", and "dns base64 txt record", located under the "Session Analysis" meta key. These tools will encode the data in the TXT record due to the limitations placed on the record type, such as only allowing printable ASCII symbols and a maximum length of 255 characters. 

From the screenshot below, we can see a suspicious sounding SLD with a large number of NetWitness sessions that would be worth investigating.

From here, I like to open the "SLD", "Hostname Alias", and "DNS Response Text" meta keys. What you can see from the screenshot below is a large number of unique "alias.host" or "dns.resptext" values to a single SLD; which is indicative of possible DNS tunnelling. The requests are highly unique, so they are not to be resolved by the local DNS cache, or the cache on the internal DNS servers.

The screenshot below shows the elevated number of different TXT records are related with the single SLD "slbwyfqzxn".

NOTE: Some commercial software packages such as antivirus and antispam tools show a similar behaviour and exchange data over DNS TXT record for their own security checks.

 

Reconstructing the sessions, we can see the TXT records and use the in-built Base64 decoding capability to see what data was encapsulated. In the screenshot below, we can see the initialisation of an SSH session:

 

Conclusion

DNS is commonly overlooked and an area that defenders should pay more attention toward, it is a great way to exfiltrate data out of an otherwise “secured” network. DNS2TCP is just one of the tools that allows data to be encapsulated within DNS, there are many others, but they all have similar behaviour and can be identified using similar techniques as shown in this post.

WireGuard is a new open-source VPN protocol used to create point to point tunnels. It uses the most modern cryptographic protocols and it works on the network layer for both IPv4 and IPv6.
One of the advantages of WireGuard implementation is the size of it's code. It uses just 4000 rows of code, which is much smaller compared with openVPN or IPsec implementations.  Initially released for the Linux kernel, it is now cross-platform and widely deployable.  All these aspects make the WireGuard protocol a perfect software for those who need to create a secure channel.

 

Considered it's easy implementation and it's wide availability, I tried to create a parser to help to identify this type of traffic.

 

For our purpose we can ignore the header of the packet and concentrate on the payload data only.

first packet

From the payload analysis we see that the first packet starts with 01 00 00 00. The same pattern is used on the following packets, 02 00 00 00 on the response and 04 00 00 00 on the rest of the traffic.

second packet

third packet


If we cross reference this with Wireguard’s documented protocol, we can confirm that the data begins with an 8-bit pattern (0100 0000, 0200 0000, 0400 0000), so we can assume that these pattern will help to identify this type of traffic.

 

With some suggestion from Christopher Ahearn, I started to create my LUA parser.

 

The entry point for my parser is the token 01 00 00 00

WireGuard:setCallbacks({
    [nwevents.OnSessionBegin] = WireGuard.sessionBegin,
    ["\001\000\000\000"] = WireGuard.tokenMATCH, -- find the token 1 0 0 0
})

Once the token is identified inside a session, it's necessary to understand its position as we are looking for the payload that have that token on the first 4 bytes of the payload. 

function WireGuard:tokenMATCH(token, first, last)
    -- check if the token is on the first 4 bytes
    if first == 1 and last == 4 then

If this is the case, then I go to define the request stream and the response stream, then I look for the pattern that I identified before: 02 00 00 00 on first packet of the response stream and 04 00 00 00 on all the other packets.

if requestStream and responseStream then
    -- the first 4 bytes on the first packet response are 2 0 0 0
    if nwstream.getPayload(responseStream,1,4):find("\002\000\000\000",1,4) then
-- the first 4 bytes on the other packets are 4 0 0 0
if (nwpacket.getPayload(requestPacket,1,4):find("\004\000\000\000",1,4) and
    nwpacket.getPayload(responsePacket,1,4):find("\004\000\000\000",1,4)) then

If all the first 4 packets respect the pattern, it means that the analyzed session is a WireGuard session and the parser set the service type as 51820. WireGuard doesn't use a specific port for the communication, so i decided to use the 51820 because it's the value used on the configuration sample available on the WireGuard website.

nw.setAppType(51820)
nw.createMeta(self.keys.ioc, "WireGuard VPN")

 

Once I deployed the parser on the Network Decoder, it allows us to quickly identify if WireGuard VPN traffic is established on the network.

NetWitness

 

WireGuard is evolving and it is possible that something will change, but this parser can help to identify some VPN traffic that otherwise would not have been defined properly using RSA NetWitness.  

Filter Blog

By date: By tag: