Good security analysts don’t just consume content, they create it. If you’ve ever read an article or blog that has sparked an idea, perhaps about a novel way to fortify your defense posture, you’re not alone. When you’re collecting rich metadata from your network, reading security articles becomes far more fun. You can now play-along, so to speak, without needing to engage engineers, change-management etc. You’ll be amazed what can be discovered by doing this. When your team is empowered with vast, queryable visibility, your security maturity only grows.
Although the discoveries your team will make by performing the exercise described below won’t always conclude by scrambling the Incident Response Team, they will lead to actionable information creating peace of mind. At the end of this exercise we will create a rule to capture our efforts; this rule will automatically produce new content when new data is received. This new content creation serves three purposes. First, it strengthens the security posture of our network by producing a tangible signal identifying suspicious activity. Secondly, when shared, the content serves to protect the wider community that may go on to produce even better content in turn. Third, and most importantly, providing the ability to capture the result of an analysis easily empowers and satisfies the analyst. Security operations can be a daunting mission with overwhelming negative feedback mechanisms, there needs to be more positive feedback opportunities available, performing this healthy habit is one of them.
We’ve hand picked a blog post from securityaffairs.co. It was chosen for this exercise because it’s short, relevant, and easy to digest. We’ll use Zeppelin notebooks with the data available from a Jask Trident deployment for our explorations.
Our adventure begins while reading an article from securityaffairs.co. The article is compelling, and outlines the evolution of the EITest campaign that is using a new flavor of ransomware – CryptoShield 1.0, and being delivered via Rig Exploit Kit (RigEK vs. Angler EK). Within the article is a network communication overview diagram of the infection as it occurs.
Screenshot from blog article showing network activity during RigEK compromise http://securityaffairs.co/wordpress/55878/malware/cryptoshield-ransomware.html
Signal Idea (Hypothesis)
Looking closely at the diagram with seven requests, there are many possibilities for exploration using our own traffic metadata. All seven connections, summarized as rows at the top of the diagram, represent HTTP data similar to what Jask sensors are already providing. In fact, all of the columns (save for the packet numbers) are indexed and ready for querying.
Below are a few quick exploration topics one might gather after reviewing the diagram.
- IPs 18.104.22.168, 22.214.171.124, 126.96.36.199, or domains thesportspost[.]com, turkiye2075[.]com
- URI pattern seems to be predictable
- HTTP POST to an IP address
- Content types application/x-shockwave-flash, application/x-msdownload
The IPs and hostnames are good for a cursory query, but not so good for signal creation into the future. We’ll leave these to our Threat Intelligence process/vendor.
Of the remaining choices, let’s pick on this one – HTTP Post to an IP address. Sending a web form POST to a web host without a name (hence the IP address in the Host column) seems strange.
Zeppelin Notebook query (Experiment)
Now for the fun part. We’re going to iterate on the idea that a HTTP POST request, where the client header contains an IP address in the host field, is strange. We’ll write the query as below looking for exactly that:
We’ve included many fields by design, this allows rapid evolution of the query. These key fields allow the analyst to use zeppelin’s powerful visualization capabilities to explore the records that match without needing to modify and re-execute the query.
There are many results that return from our first query. It may seem at first that our hypothesis was proven wrong. Before we give up, we’ll examine the results and begin pruning away to see what’s left. With only a couple iterations, this query has tightened up to now only identify highly unusual and infrequent HTTP activity. Let’s look at the process of weeding out some noise.
Scrolling through the results in grid view, we notice a lot of connections to Akamai destinations that match our suspicious pattern, with a shockwave flash user-agent.
Some open source research confirms this communication is consistent with Akamai NetSession; it looks like it’s a peer-to-peer agent often used for streaming services such as Netflix etc.
Let’s switch to a bar chart to see if we can isolate these by using destination organization and user agent string.
Looks like we can. Building the logic for that is simple. Add some SQL to exclude the Akamai NetSession traffic, now rinse and repeat this analysis process for all other matches. The goal isn’t to get to zero, but to reduce the number of hits for the query to a low volume.
We may have just identified a policy violation or two with this. It’s important to respond appropriately to discoveries we make while performing analysis on our suspect connections; we have folks using a p2p agent associated with video streaming. But don’t take your eyes off the prize, the goal is to identify unusual traffic pattern that corresponds to hostile activity that we learned about in our blog post. This traffic is definitely not that.
Here’s a summary of the two analysis iterations performed that got our results down to less than 5 records per day:
After reducing our output records to a fraction of what they were with only two localized filters, one for Akamai NetSession and one for Fortinet updates, we have proved our hypothesis true. It is indeed unusual to see web POST requests carrying an IP address in the client’s ‘host’ header. There are only two things left to do:
First, perform a deep investigation on the hosts remaining that are exhibiting this unusual behavior. Depending on your data retention, you may have discovered an infection that occurred some time ago.
Secondly, capture this analysis. If you’re using Jask’s Trident product this is accomplished through the Filter dashboard in the UI. In Trident, this allows artifacts (known as signals) to be produced on any new suspicious activity. This task is simple, first copy-and-paste the query logic to the patterns UI. Next choose a category and priority then enable it. Category and priority selection is essential for Jask’s automated analyst to gain the most use of it.
If you have large amounts of metadata covering your network, with a little practice, your team can begin moving the security-maturity higher for your organization every day. Remember to stay focused on the objective, analysis rabbit holes (e.g. Akamai NetSession traffic) are everywhere and can interrupt the rhythm of your content creation.