Threat detection with Snort – Win32.Noon

Written by  on April 24, 2018 

In the previous post about snort, we were talking about what can this NIDS do for us as network administrators / security researchers in matters such as threat detection and blocking acting as a firewall or in other topics such as a subsystem in bigger threat detection systems, we were also talking about using snort as a tool for helping in the threat research process by parsing pcap files searching for malicious activities.

Also as you may have noticed, we were only talking about using snort for detecting traffic coming from outside our network to our machines, which makes a lot of sense if we are thinking about defending systems against remote exploits or protecting web applications. Today we’re going to see how to use this program to peek inside traffic coming from our machines to outside. This case is particular useful when we are talking about malware analysis as the malware may use the network to connect to a command and control server outside, usually crafting its requests to look like legit http requests.

So we are going to start this series by analyzing the traffic obtained from the “Trojan-Spy.Win32.Noon” malware. I have to personally thank my collage Tatyana Shishkova from kaspersky lab for providing me with some really cool traffic samples to play with and some other rule examples to analyze 🙂

 

A first look into the pcap file

Right after getting our traffic sample we need to figure out what’s going on there. You may take different approaches once analyzing the traffic and I don’t consider my self a top expert on the field. One of these approaches if the pcap size ain’t too big is to make a quick view over the packet to figure out which protocols are taking part in the session and then start scrolling and stop whenever interesting happens. For example if we look at the following pcap file we can easy see that we are about to work with a malware that uses http for CnC communications. So for example, we can start looking at the DNS queries that the malware does.

Here we see a couple of DNS queries, let’s see where it goes:

Detecting malicious DNS queries

That malware is looking for brijvikastrust.com, after doing some RE and doing further analysis on the traffic and consulting different IoC sources we can be able to confirm that brijv… is an evil domain used as a CC server. So if we have that domain identified as evil, every software trying to communicate with it may be identified as a malware or an infected software. This will be our first approach on identifying and blocking the malware. Let’s extract our domain signature for snort.

By simply clicking on the domain query on wireshark we can get a pretty simple example of what to tell snort to look for in a packet. So a quick filter may be something like:

alert udp any $home -> any 53 (msg:”Evil domain req.”; content:”| 01 00 00 01 00 00 00 00 00 00 |”; depth:10; offset:2; content:”|03|www|08|brijvikastrust|03|com|“; nocase; distance:0; fast_pattern;

With that we tell snort to search inside UDP packets FROM our network to remote servers at port 53 then to look for a sequence of bytes such as “01 00 00 01 00 00 00 00 00 00” which was extracted from our packet capture and can be found at the begining of a DNS query, then we specify that we have to look for that in the first 10 bytes at the second offset. Then we follow looking for the evil domain name, making no distinction between upper and lowercase, we search for that just right after the first match and with fast_pattern we’ll search for that only if we have our first match. Fast_pattern is really useful for making things work faster and non-overloading our nids.

Examining the http traffic

But what if the attackers just move their CnC panel to other domain and re launch the campaign? We may think about doing a more in depth analysis to look for something more relevant and unique inside the traffic. As we saw before, this is an  http connection so let’s go and see what’s happening there:

So we see that noon is trying to perform a GET request to some control panel hosted at that domain filling a parameter called id with some letters, numbers and symbols there. We can also see that right after seeing that GET req, we immediately see a close to the connection.

If you were playing with the previous post about snort, you may think that regex may be really good for this. Let’s try to figure out a regex for matching this url:

Something like that may be helpful in a PCRE for triggering an alarm when that url is called. Let’s figure out a snort rule now:

alert tcp home any -> outside 80 (msg:”looks like win32.noon”; flow:to_server, established; content:”GET”; http_method; content:”/?id=”; http_uri; fast_pattern; pcre:”/GET \/[a-zA-Z0-9\/]+\/\?id\=/”; content:”Host:”; http_header;…

Here we can see that we look for tcp traffic going outside at port 80, going to the server and also looking for an established tcp connection (you may have any doubts, see this), then we start looking at a GET request, we do that by specifying GET in a content tag and right after specifying http_method, so snort will only search by GET requests now. Then we look for something that contains /?id=  as a URI which looks pretty genuine and then if we find that match, we use a PCRE regex to match that URL. Finally we look for an http_header containing “Host:”. Note that using fast_pattern here is pretty useful as we launch a regex right after.

With that rule we can easily detect that evil url.

False alarms

But, what if our client is trying to use a web application like this one:

We definitely get a false positive here. So we can try to solve that out adding more filters for preventing a false alarm match. By looking more on that http connection we can see that we see no Accept and User-Agent fields in the header and we see these it other legit applications so we may add something like:

content: !”Accept”; http_header

and

content: !”User-Agent:”; http_header;

We also may want to add something like:

content:”Host: www.”; http_header;

To add mor precision. We dont add the full domain name as it may change from time to time.

Generating custom network signatures

So, another thing we may want to do and I recommend as a general strategy for research threats is to look at more pcap files and analyze them, searching for patterns.

If we look a little bit more we see:

and

So we see a file hosted at a folder from 2 chars to 5 and then our alphanumeric+simbols url calling at an id param.

content: “GET”; http;method content:”/?id=”; http_uri; fast_pattern; pcre:”/GET (\/[a-zA-Z0-9]{2,5}){1,}\/\?id\=[a-zA-Z0-9_\-\.\+=\/]+ HTTP\/1\./”; content:”Host: www” and everything we saw before

We look for the folder where the panel is hosted and then we look for the malicious url making sure it doesn’t target legit services.

 

And here we go with that! I’ll be doing more related stuff.

 

Category : hacking seriesinteresting stuff

Tags :