Despite leveraging a signature-less approach to identify suspicious or potentially malicious activities may result challenging without knowing the context of the analysis, it always proves to be the most flexible and effective way to do things as we start defining what we want to look at. Nowadays more than ever many (nasty) things pass through our network security controls and it cannot be otherwise if we want the business of our companies to survive or continue growing. On the other side, attackers are there to exploit those trusted paths and flows, along all the different phases of a typical kill chain, from reconnaissance to the data exfiltration.
The traffic entering our network is probably one of the most analyzed piece of data in our organization. Many different signature-based security tools are looking carefully at it to block or identify malicious activities. But there is always a whitespace left behind they cannot address and this is where Security Analytics comes into play. The generation of meta information, combined with the threat intelligence and the ability to dig at any time into the raw traffic to reconstruct quickly the sessions allows addressing this gap potentially left open to our attackers.
To prove the concept (as I always try to do in my posts) I put together some sample rules to identify suspicious or potentially malicious activities related to the inbound network traffic.
The first step would be to identify what is entering our organization versus what is leaving it but this proved to be an easy task to accomplish, as discussed in https://community.emc.com/thread/198366.
The second key point is defining what to look for. Even if there are scenarios (and hence rules) which would apply to any situation and environment, it is always better if we want to increase the accuracy of the detection, to leverage the context the product is running in. Never underestimate the importance and advantage of knowing your own environment.
A good starting point would be to look at your traffic, trying to identify interesting use cases and potential means through which an attacker would exploit an existing trusted channel. To do so, try to focus on a specific use case (e.g. inbound traffic like here) to avoid facing too much data hence losing the focus. Once identified the scenario, convert your set of queries into rules, eventually grouped together into a single, comprehensive report.
By leveraging this approach on a specific environment, I came out with the following sample rules:
- Hostname is an IP address: when the attacker connects to a web server without providing a hostname but calling directly the IP address
- DNS Fingerprint: when the attacker tries to reveal the version of your DNS server
- FTP Attempts from foreign countries: when an attacker tries to identify FTP servers exposed to the Internet
- HTTP PUT on txt file: when the attacker tries to exploit a vulnerability and write code into your webserver
- PHP pages requested with errors: when the attackers tries to identify vulnerable PHP web applications exposed
- Shellshock attempt detected: when an attacker tries to identify a web application vulnerable to shellshock (https://community.emc.com/community/connect/rsaxchange/netwitness/blog/2015/03/09/shellshock-attempt-in-ua-string)
- Unknown traffic from suspicious countries: when the protocols attackers are leveraging are unknown to the platform and then suspicious
- Zmeu vulnerability scan detected: when an attacker is using a publicly available web application scanner against your network
Somebody may argue that part of those rules can be implemented also in other existing security controls and I’d agree. But the differentiator when working with Security Analytics is that the outcome of such a report represents just a starting point to kick off an investigation to answer more interesting and challening questions such as “what other requests did the same source do against your network?”, “what kind of payload has been used?”, “what other relevant meta can be leveraged to gain the full picture?”, “is there any callback to some of those suspicious IP sources?”, “was that a single probe from a script kiddie or something part of a more sophisticated attack?”.
All of those questions will never remain unanswered and, more important the answers are those which really matter to help protecting the business of organization.
All the rules and a report including them all are attached to this post and can be imported in Reports -> Import.
Disclaimer: please DO NOT consider what is described and attached to this post as RSA official content. As any other unofficial material, it has to be tested in a controlled environment first and impacts have to be evaluated carefully before being promoted to production. Also note the content I publish is usually intended to prove a concept rather than being fully working in any environments. As such, handle it with care.
