Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > Author: Massimiliano Faudarole

Every SOC analyst should spend at least part of his/her day reading various blog posts and white papers on attacker profiles and their tools and techniques. Attackers often repeat at least certain aspects of their activity on various targets, and thus provide the analysts with an opportunity to incorporate such indicators into their toolset (hopefully) prior to being targeted by such attackers.

 

In addition, other sites provide continuous indicators of both advanced and opportunistic attackers, which can also be incorporated into the toolset for automatic detection.

 

Here I will provide a guide on how to format such publicly available indicators into the NetWitness Network and NetWitness Endpoint.

 

Let us briefly describe what is an Indicator of Compromise (IOC). An IOC is an indicator of something that has already been observed on a compromised system or a behavior that was part of an attack. There are multiple types of IOCs, because you can track something in many different ways, for example IP addresses, filenames, file size, URLs, a particular endpoint behavior, etc.

 

Sometimes lists of hashes such as MD5/SHA1/SHA256 are enough to quickly identify compromised machines. For this purpose, there are multiple sites where you can find a good list of MD5 / SHA1 / SHA256 based IOCs, here are some examples:

 

 

At this point, if you don't have your own list of IOCs based on MD5 / SHA1 / SHA256, you can use some of these lists, created by other analysts. However, such information is not necessarily in a suitable format for incorporating into the NetWitness toolset. One way to normalize the data is by following this process:

 

  1. Install Cmder (https://cmder.net/), which is a good console emulator for Windows that has the functionality needed for the rest of the steps.
  2. Let’s say you want to generate the MD5 list of IOC FIN7 found at:
  3. https://github.com/RedDrip7/APT_Digital_Weapon/tree/master/FIN7

 

After you download file FIN7_hash.md, you are ready to start.

  1. Open Cmder and go to the folder where the downloaded file is located.
  2. Now run following commands, as shown in the following figure.

 

grep -e "[0-9a-f]\{32\}" FIN7_hash.md | cut -c 3- | cut -c -32 | uniq -u > FIN7_tmp.txt | sed -e 's/$/,FIN7,blacklisted\ file/' FIN7_tmp.txt > FIN7_md5.txt

 

Let me explain the commands in more detail for those not familiar with these tools/commands:

 

CommandDetails
grep -e "[0-9a-f]\{32\}" FIN7_hash.mdExtract MD5 from file FIN7_hash.md
cut -c 3- | cut -c -32Remove all the unneeded characters
uniq -u > FIN7_tmp.txtMake it unique and save the output to FIN7_tmp.txt
sed -e 's/$/,FIN7,blacklisted\ file/' FIN7_tmp.txt > FIN7_md5.txtCreate the final file

 

 

The above steps are specific to this particular file, each set of IOCs will need its unique set of conversion steps, add “,FIN7,blacklisted file” to each line and write the output to FIN7_md5.txt. Where “FIN7” is the description of your APT, which we will map to the ioc key in NetWitness, and the value “blacklisted file” which we will map to the analysis.file key, this step is critical if you want the module and machine scores automatically set to 100 for these matches.

 

Figure 1

 

If you want to use your own toolset to format the data, then please ensure you follow these steps in order to generate a good list of IOC:

 

  1. Retrieve the file (can be a plain text, a pdf, a word, one HTML, the filetype is not important)
  2. Extract the IOCs from file
  3. Remove unneeded chars (in order to have only the useful strings)
  4. Make any IOC unique (ensure you remove any duplicate entries as this in an important step)
  5. You must have a value of “blacklisted file” in your resulting file if you want machine and module  scores to be affected by your feed.

 

At this point we have the source CSV file with the data necessary to create a Feed for NetWitness Endpoint.

 

To create your feed, follow these steps:

  1. Go to Configure->Custom Feed and create a custom feed.
  2. Click on + icon, select Custom Feed and configure the custom feed by giving it a name and selecting the CSV file you created above as shown in the following figure

 

Figure 2

 

 

In this case CustomAPTFeed.csv is your FIN7_md5.txt created above, which we renamed to CustomAPTFeed.csv.

Apply the feed to the LogDecoder (second Tab), and define the Columns as shown in the following figure. Here define the Callback Key as “checksum.src”, select Index Column to be the first one, which will grey it out in the grid below, select the key for Column 2 in this case “ioc” and finally select Column 3 as the “analisys.file” meta key, again this step is critical if you want the risk scores to automatically update, it will only work for this combination of key and value.

 

Figure 3

 

 

Finish the import make sure there are no errors and the task completed successfully. Now you can go to Investigate in the UI and validate your data.

 

Every time the meta key “checksum.src” contains a value defined in your custom feed, meta key “ioc” will be populated with the value provided in the Column 2 of the CSV file and the “analysis.file” meta key will have the “blacklisted file” value, as shown in the following figure.

 

Figure 4

 

In this case, the endpoint risk score for that system will automatically be increased to 100 (the highest possible risk score), and under Critical Alert you will see the relevant indicator in our case that is “Blacklisted File”.

 

Figure 5

 

The same will happen to the specific module that was Blacklisted, as shown in the following figure:

 

Figure 6

 

Multiple types of IOCs can be loaded into NetWitness Endpoint, following the steps presented in this blog post. Always remember that IOCs are static, so the resource has to match exactly to trigger an alert. In the case of MD5 hashes of files, also remember that if the file is changed even by just one byte or for example recompiled, the MD5 hash will be different and your IOC will no longer match. This is the reason why we recommend that analysts focus instead on other possible characteristics of a file (such as the file description if it is unique) or its behavior (such as any parameters that need to be passed for it to work).

 

I hope this blog post can help in importing simple and fast IOCs into the NetWitness endpoint for automatic detection of known malicious files.

 

A special thank you goes out to Lee Kirkpatrick for his assistance and support.

Introduction

There are many, many ways to exfiltrate data from a network, but one common way to do it is using DNS Exfiltration.

With these specific techniques the attackers use the already open port for dns traffic as the door for uploading and downloading data between the attacked host and his own external server.

 

Obviously with the normal daemon for DNS resolution that’s not possible, but with the right software and the right configuration it is possible to use any DNS server and set it up within any infrastructure to exfiltrate data without the right permissions needed.

 

But how is possible?

 

There are many packages already built which are ready to be used for this purpose and the most common are: Dnscat2, Iodine and Powercat+Dnscat2.

 

Just a quick tip, don’t imagine an attacker using a specific version built only for you.  Attackers are lazy and they need to be sure their attack is efficient, so most of the time you will end up fighting with one of these three DNS exfiltration tools.  They'll either be renamed or exactly the same as you can find on GitHub.

 

Remember to also check the second level domain to avoid any confusion with legitimate software using dns tunneling.

 

So, let’s take a look into these three tools, both work for the same purpose and same TCP/UDP port but with some difference in how to send the data outside the network:

 

Dnscat2 (https://github.com/iagox86/dnscat2): it connects to a server component to try to resolve TXT queries and all data going up and down, to and from, the external server in an encrypted way or not, depending on your choice. This tool is widely used, also because it is ported into multiple programming languages, like Ruby, Perl, PowerShell, etc. This way it can be easier to implement and it'll essentially work on any network.

 

Iodine (https://code.kryo.se/iodine/): same basic functionality as previous one, make tunnel through DNS, but with little difference like password for accessing the tunnel, and uses the NULL type that allows the downstream data to be sent without encoding. Each DNS reply can contain over a kilobyte of compressed payload data; there’s also the android version, so all the work is almost done for example to implement it also on IoT device running Android.

 

Powercat (https://github.com/besimorhino/powercat): that tool alone don’t work as a dnstunnel, but if the server part is dnscat2, you can have a interactive Powershell over legitimate dns traffic, and you can increase your capability by adding other Powershell attack framework like Nishang, Powershell Empire, etc..

 

The purpose of these article is not “how to exfiltrate data from a network”, but let’s take a look how our products can help you to identify and track any usage of these technique in your network, and for that I’ve choose the common approach used every day by me and my colleagues of Incident Response Services.

 

For that I’ve choosen RSA NetWitness Network. Let’s take a look at the essential steps.


 

Preparation

In your NetWitness Network click on configure, select as Resource Type Bundle, click Search, choose Hunting Pack and click on Deploy to deploy the hunting pack as showed in Figure 1 to the appropriate component of your infrastructure.

Figure 1

 

Now choose Lua Parser as Resource Type, click Search and choose nwll and DNS_verbose_lua as parser and click on Deploy to deploy the parser as showed in Figure 2.

Figure 2

 

Now that your NetWitness Packets (network) environment is ready and have all you need to parse and identify in the right way DNS traffic you can start with your analysis.

 

Now let’s see how to find bad DNS traffic, or better, the traffic who cross DNS port but is not a real DNS traffic.

 

 

Dnscat2 traffic

With right package and parser deployed, if there’s traffic generated by Dnscat2 into your network, many indicators rise to your eyes and help you to fast identify it.

Figure 3

 

As showed in Figure 3, for Service Type = DNS (service = 53) Service Analysis show presence of “dns base36 TXT record” and “hostname consecutive consonants” plus “dns large answer” as Risk Information and “Hostname Aliases” like the hostname showed in Figure 3 are good sign Dnscat2 traffic presence.

Scrolling to the others meta keys as showed in Figure 4 you find DNS Query Type with value “txt record” and DNS response text with values of many chars without apparent sense, now you have sufficient alerts!

 

 

Figure 4

 

So, in my network there are query for txt record, with base36 encoding, large answer, apparently random text response and random chars host alias? To be sure that’s not a normal DNS traffic you can click on one of these events and see what inside as showed in Figure 5……

 

Figure 5

 

Now you have clear that you are in front of Dnscat2 traffic and you have to do further analysis on Source Ipaddress who generate this traffic.

 

A quick query i apply every day to find its presence in the preferred time span, can be: service = 53 && dns.querytype = 'txt record' && analysis.service = 'hostname consecutive consonants' && analysis.service = 'dns base36 txt record'


 

Iodine traffic 

Let’s check some interesting meta who give me the ability to find Iodine traffic.

 

Figure 6

 

As showed in Figure 6 there’s Service analysis with “hostname invalid” and “hostname consecutive consonants”, Risk Suspicious with “dns extremely low ttl”, Host aliases with a lot of “strange” hostname, but check if there’s something more…

 

 

Figure 7

 

As showed in Figure 7 there’s also another interesting filed, DNS query type who say “experimental null record”, so job done, all of these meta are related to Iodine activity and the packet showed in Figure 8 confirm the traffic.

 

Figure 8

 

Now you have clear that you are in front of Iodine traffic and you have to do further analysis on Source Ipaddress who generate this traffic.

 

A quick query i apply every day to find its presence in the preferred time span, can be: service = 53 && dns.querytype = 'experimental null record'

 


 

Powercat + Dnscat2

Looking into Powercat + Dnscat2 is different from previous one, let’s check why.

As showed in Figure 9 Session analysis say “single sided udp” , Service Analysis say “hostname consecutive consonants”, dns base 36 txt records”, “dns single request response” and Hostname aliases have a lot of hostname with strange names.

 

Figure 9

 

Looking on more meta as shown in Figure 10, there’s DNS query type as “txt record” and DNS Response text with a lot of strange text starting with same char.

 

 

Figure 10

 

Look similar to Dnscat2 traffic but not exactly the same there’s a specific difference between standard dnscat2 traffic and be the “single side udp” and “dns single side request response”.

 

Figure 11

 

As showed in Figure 11 there’s only one request and one response, and that’s the main difference from standard dnscat2 and Powercat with Dnscat2.

Now you have clear that you are in front of Powercat with Dnscat2 traffic and you have to do further analysis on Source Ipaddress who generate this traffic.

 

A quick query i apply every day to find its presence in the preferred time span, can be: service = 53 && analysis.service = 'hostname consecutive consonants' && analysis.service = 'dns base36 txt record' && analysis.service = 'dns single request response'


 

Addon

Most of the time, when you look into DNS traffic, maybe you encounter something like a client who work not only with UDP but also with TCP protocol.

If the information about the source is right, with these hunting methodology you can archive also some goal about network misconfiguration.

That’s because DNS infrastructure need to be managed and there are a lot of guide on "How to secure your DNS infrastructure", so in a normal situation a client try dns resolution through one internal server, most of the time a domain controller, who talk with a DNS forwarder allowed to go outside of the network for resolution ( if both have nothing into cache).

So if you see a client go to ask resolution from client network to internet , also with TCP protocol, is better if you check more your DNS infrastructure, because one backdoor on client machine using port 53, probably have direct access to internet and you can exfiltrate everything without usage of any dnstunnel, but only using the port allowed.

 

A quick query i apply every day to find its presence in the preferred time span, can be: direction = 'outbound' && service = 53 && ip.proto = 6 and if your source ipaddress are filled with a lot of ip coming from client network, you have some possible misconfiguration into the network and/or some possible hole.


 

Finally

There are many ways to hunt and dig into a system, but with the right product and the right methodology you can archive success very faster and this article want be a quick help on doing that because every day we do that with our products!

 

Hope this helps.

 

Thank you.

 

Max

 

 

Filter Blog

By date: By tag: