False positives are an everyday occurrence for analysts. To an analyst, a false positive, while sometimes time consuming, offers an opportunity to have a rule tuned or removed in order to save valuable analysis time. However, what happens when a signature hits correctly as it should, though the customer is not at risk? Its a “true positive false positive”.  At Morphick, we call these Benign True Positives.

Benign true positives are not extremely common, although they do tend to show up every couple of weeks. While still a false positive in regards to protecting the customer, these alerts usually offer an interesting story and in some cases intelligence value.

Analysis

As a security practitioner,  many alerts that come in are interesting for me. Given the relative rarity of a webshell alert and the exciting possibility of a true positive hit on a webshell, these alerts always pique an analyst’s interest. This was certainly the case last week when an alert for WSO Webshell Activity rolled into my queue. Below is a run-through of my analysis/thought process while working the alert.

Signatures use pattern-matching techniques in order to identify malicious traffic, be it specific identifiers in code, specific network traffic, etc. In this case, the pattern was simple; the signature fired on the title of the webshell, “WSO.” With a quick look at a tcpdump of the traffic, we can confirm the match:

Perfect! The signature worked as intended: it matched WSO (the name of the webshell) and fired an alert. (Simple, but it got the job done.)

I was able to find the webshell source code in case we wanted to do some R&D on new signatures – it can be found here:

https://github.com/tennc/webshell/blob/master/php/wso2.5.1.php)

Next, let’s peek at the HTTP logs (private information has been redacted):

1464030666.974887    C8feID2vJLKNwz2Guk    x.xxx.x.xx    65185    xx.xx.xxx.xx    8080    2    GET    www.counterwebsitenamehere.com    http://www.counterwebsitenamehere.com//counter.php?page=wordpresssitenamehere.wordpress.com/&digits=24&unique=0    -    Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.94 Safari/537.36    0    21851    200    OK    -    -    -    (empty)    -    -    PROXY-CONNECTION -> Keep-Alive    -    -    F8fFMA4vGvKrY550J9    text/html

Here we see the client making an outbound request to www.counterwebsitenamehere.com.  Browsing to the counter.php page listed in the HTTP logs shows what is happening. The server that hosts counterwebsitenamehere.com has been compromised and the WSO webshell has been installed.

Now that the relevant information has been gathered, we need to build a story. At first glance, it appears an employee at the client’s site could be browsing to a webshell of an owned server. While possible, this seemed rather unlikely. Looking back at the traffic, we see counter.php?page=wordpresssite.wordpress.com in the referrer. This was fairly interesting, so I took a look at how the counterwebsitenamehere.com code worked.

In order to see the code that the counter website created, I quickly generated my own counter. When a counter is generated, this code is created:

<img src="http://www.counterwebsitenamehere.com//counter.php?page=http://www.counterwebsitenamehere.com/&digits=1&unique=0" alt="free counter" border="0;">

​Given this information, it appears that the WordPress site had a counter on it from counterwebsitenamehere.com. When the user browsed to the WordPress site, a request was generated to counterwebsitenamehere.com/counter.php?page=wordpresssite.wordpress.com in order to increment the counter.

The interesting part is that when the threat actor compromised the webserver, he tried to hide the webshell by naming it counter.php. This created an interesting interaction though, as whenever the counter request was generated by the counter code, the resulting request would be a request to the webshell rather than the counter code.

Conclusion

As the webserver hosting counterwebsitenamehere.com being compromised posed no threat to our client, this alert was considered a benign true positive.  The signature fired as it should have, but the client was not at risk. Still, pretty interesting for a no-risk situation, right? 

Even though there was no risk to our client, I found this analysis interesting and hope you do too.  At Morphick, our analysis goes deeper, beyond simply validating the alert, in order to truly understand what is happening inside our client’s environments.  This depth of analysis serves to keep the noise of useless alerts down, but also protects them better.  This is just one of the ways that Morphick’s Managed Detection and Response changes the game.

By the way, the webshell was removed from the compromised site…just in case you were wondering.