Four “Red Flag” SOC Phrases

Security is a hot-button issue in businesses today to a degree we haven’t seen before. For the C-suite and other business leaders that begin paying more attention to what’s going on in the SOC, it can be like entering a foreign country – full of customs and phrases that are as difficult to interpret as a whole new language.

CISOs and senior security staff end up playing an important role as translator. However, it can be challenging to distill complex SOC dynamics into bite-sized issues that the company can recognize and overcome.

This barrier has contributed to problems such as security blind spots, job dissatisfaction among analysts and the ever-growing skills gap – big time, top-of-mind challenges for the security industry. That’s why I recently penned an article for Dark Reading, called “SOC in Translation: 4 Common Phrases & Why They Raise Flags.” It begins:

Having worked in many different security environments, I've picked up on more than a few phrases that you hear only in the security operations center (SOC). These catchphrases frequently need translation — especially as CISOs and the entire C-suite look to get more involved with their organizations' security practices.

Below are a few to listen for, along with what they mean for the business.

If you’re running into communication barriers within your SOC or between security teams and business leaders, I recommend giving it a quick read. Being able to interpret these four phrases can save your business a lot of headache, and point you in the right direction when it comes to selecting new security tools and positioning your team for success.

The full Dark Reading article can be found at:


Habits of Highly Effective SOC’s: From Security News to Content in One Hour

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 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.

Source material

Our adventure begins while reading an article from 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

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,,, 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.

IDS Autopsy


If you’re in the IT security industry, you’ve certainly heard that IDS is dead. It’s funny to hear technology personified this way. Someone call 1110001111! The thought of a security technology expiring can be daunting, are we losing the battle? What’s the cause of death? We can include in the list of causes the high numbers of false-positives, lack-of security analysts, non-performant hardware etc. However in this post we’ll examine IDS evasion as one of them that contributed to its demise. If you’ve been around the security industry for a while, you’ll surely remember some of the techniques that we’ll explore in the Cat and Mouse section. After the nostalgia party, let’s change perspectives towards the future and take an optimistic look to what’s in store for the cyber warriors out there.

IDS can mean a lot of different things. Before we get started let’s disambiguate a bit. This article deals with network intrusion detection systems (NIDS). You know, the devices that hang out on the edge of your network, snooping on everything and sending you tons of alerts. It’s the one screaming at you to pay it attention, like the car alarm in the parking lot at 2:00am.

Cat and Mouse

Circumventing IDS has been a game played for decades. Below I’ll reflect on some of the techniques that were successfully used to sidestep IDS detection. This is important to understand; the ease of avoiding security controls is a primary reason for the death of a security technology.

Obfuscation Fragmentation

An obvious way to sidestep a network IDS is to simply scramble up the data in such a way that’s easy for the recipient to deal with, but difficult for the IDS. For instance, if a signature is looking for the phrase, “Command: Download all credit-card data”, we can simply break it into chunks, (“ownl”, “all cr”, “edit-c”, “Comm”, “ard da”, “and: “, “D”, “oad ”, “ta”) before sending it along out of order. At first this was done at layer four, the chunks were TCP/UDP datagrams. This is effective because the receiver of this message can easily reassemble it. If the receiver can’t, signaling for a retransmission is trivial. A network IDS that is listening to every conversation on the network cannot easily keep up and perform the reassembly required. IDS preprocessors were introduced to deal with this. With a layer-four statefull preprocessor, the IDS could reassemble the datagrams in the right order before checking for any pattern matches. We’re all fixed, right? Not quite yet, why not break the datagrams into smaller pieces and scramble them too? IP fragmentation is another technique to do the same thing, but now at layer 3.

This type of fragmentation technique requires low-level access to the operating system to perform, making it a heavier lift. It’s why we only see this technique used for attack traffic, vs. command-and-control, where much easier channels are available. It’s also easy to prevent: IP fragmentation on modern networks is very unusual and typically indicates a network configuration problem. Blocking IP fragments is safe to do and will prevent layer 3 fragmentation from being effective.

Special Encoding - Directory Traversal

Web directory traversal was a popular way to allow a hostile web client to reach outside the bounds of the remote server’s filesystem. The technique allows attackers to not only access files that were not intended for anonymous web-client access, but also interact with servers in naughty ways. The technique manifested as a web request with a large number of parent directory paths chained together. Generally it looked something like this:

Those dot-dots are a relative link pointing to the parent directory; stringing together several parent links would allow the hostile actor to “traverse” the directory tree to areas of the server's filesystem typically not for public consumption. The beauty here is that the parent of the root directory is itself. So, the bad guys don’t need to know how deeply nested the web content directories are,as  there is no such thing as too many parent directory references.

To identify the activity, IDS signatures were created that looked for a series of “../” to alert security analysts that an attack was underway.

It wasn’t long before a disturbingly easy way around detection was discovered and used. By encoding the individual characters as their percent-encoded equivalents (i.e. ‘../’ becomes ‘%2E%2E%2F’), the cat and mouse game begins. Upon discovering this new technique in the wild, a signature is written looking for a series of (%2E%2E%2F)’s. We’re safe right? Nope. Now we encode the percent sign (%) with a technique called ‘double encoding’. After our defenses are fortified against double encoding; we should be good right? Nope, now let’s use Unicode...

Those in the industry often complain about IDS false-positives, but false-negatives, which by their nature are difficult to measure in an operational environment, are more highly likely and much worse for you then false-positives. So what’s the solution here? Think about it, what can we do so we’re not dependent on these strict signatures? We’ll get to that later in “The Future” section of this post.

Low and Slow

Performing reconnaissance against your target is the first step for most nefarious activities. When this reconnaissance involves probing IP addresses and ports, your IDS is there to help you identify it. That is, unless it’s very slow. IDS detects network host reconnaissance with rate over time detections. If you move slow enough, you’ll slip right by. The IDS threshold can be loosened, however there’s a consequence. If you loosen the threshold too much, everything begins to look hostile; your IDS becomes paranoid. In other words, you will increase the false-positive rate so that the detection is rendered useless, like a whooping car alarm from the 90’s.

Undetectable C2 - DGA, and IP address fails

Establishing communications to external agents from a compromised machine is essential to hostile operations. Industry jargon calls this Command and Control (C2). C2 is the channel by which commands are conveyed, and sometimes information is extracted. Early C2 channels included static (always the same) IP addresses, and domain names. Although the protocols used varied, HTTP (TCP/80) became an early favorite as it’s almost always allowed outbound from your network, and is surrounded by loads of beautiful noise.

IP’s and domains were easy to understand and guard against by network defenders. They can be monitored, blocked, and sinkholed. IDS signatures will often include loads of IP addresses and domain names of known ‘bad’ assets. Even when protection in this way is effective, it’s a management nightmare. Most security operations I’ve encountered may have very good processes for reacting to new, known-hostile, IP addresses and domain names, but have little in the way of expiring these threat indicators. To find out if an organization has good management of these signatures, simply ask, “What’s your oldest hostile domain or IP address you watch for?” If they say, “I don’t know” or “This one from 1998…”, or “our Threat Vendor handles all of that”, you may have a problem.

The state of the art for attackers is now to use something much more unpredictable when establishing command and control: DGA domains. DGA stands for Domain Generation Algorithm. An infected host will use DGA’s to persist their C2 connection by using a quasi-unpredictable domain name that changes frequently. This avoids signature detection all together. IDS has no hope to identify these domains and the IP addresses associated with them; the hostile assets simply don’t live long enough to allow the IDS signature creation process to be effective.

Everything else - Prototyping Evasion Techniques

We’ve talked about a few of my favorite evasion techniques, but the biggest problem with IDS is that most places are using the same signature set that can be easily tested against. If you’re a bad guy trying to avoid detection, it is very easy to manufacture a communication pattern (attack, C2 technique, etc.) since many organizations use the same signature set. Because of this, even novice hostile content authors can iterate over the weapon until it comes out squeaky clean. Got ETPRO? -> You just installed a lock on your network that every bad guy has an exact copy of to practice their picking techniques on. Sure, having an IDS with common signatures deployed is better than nothing, but not by much.

The Future!

Like a phoenix from the ashes, the next evolution of security technology is rising. And it involves this subtle, but important, paradigm shift: The artifacts of active network monitoring should be a compact, detailed summary of ALL activity. They should not presume to detect attacks by emitting alarms while ignoring ALL other connections that did not match a pattern. They should emit high-confidence metrics of all activity occurring across the monitoring interface.

It’s what we do with the network summaries where the future detection paradigm becomes extremely compelling. We can apply statistical analysis, machine learning algorithms, and enhancements to the data. Most of these enhancements only become valuable within the frame of reference of the network being monitored, thwarting the single-lock problem. In addition, we can apply Artificial Intelligence to automate analysis, discovering patterns of interest from the mountain of data so fast as to compare it’s value with an entire SOC’s worth of trained analysts. (In fact, this is what JASK’s primary mission is, and we’re doing it).

Threat Intelligence now becomes much more powerful. Since most indicators of compromise from threat intelligence are contained within the network summaries (i.e. IP addresses, host/domain names, email addresses, file hashes, etc.), they can be examined after the fact. Intelligence indicating a hostile IP address yesterday offers little help to an IDS today. By storing these traffic summaries, we can apply threat intelligence over the period when it was known to be hostile, further empowering the analytics and analysts (AI or human).

So, let’s look now at the new paradigm against the attacks mentioned previously. First, the web directory traversal attack:

Here’s a sample of what a modern sensor would collect and report back of EVERY web connection. This is the “traffic summary” mentioned in this article.

Many enhancements can be attached to this summary, sourced from machine-learning algorithms, statistical analysis, static matches, etc. Here’s a few to get the juices flowing:

  • GeoIP of source, ASN name/number
  • Abnormally short client header
  • Abnormal URI - Repeated character sequence observed (“../”)
  • Abnormal URI - Rare resource requested (/Windows/System32/config)
  • User-Agent Levenshtein distance anomaly (Mozillla -> Mozilla)

You should start to realize how difficult it’s going to be for an adversary to avoid tripping all these enhanced features around the attack. Many of them source from statistical inference (e.g. the one’s with ‘rare’ in the name are unusual considering what that host/service usually does). Let’s look at the other example we mentioned earlier: Command and control to a DGA domain.

Here are some enhancements that can be applied to this traffic summary:

  • GeoIP destination, ASN name/number
  • Unusual connection to foreign host
  • Web host property carries a high entropy domain name (appears random:
  • Base64 encoded text in URI (cc=V293LCB5b3UndmUgd29uIGEgZnJlZSBKQVNLIGRlbW8h)
  • Internal host not a normal web client

What’s not shown above is the millions (or billions) of traffic summaries surrounding these two with nothing of particular interest bubbling up. It’s the AI’s turn now to stitch these two artifacts together, to begin telling a story of host compromise. Exciting, right? I think so.

Wrapping it up

So it seems IDS is dying. But it’s not dead yet. Many mature security operations rely on the IDS heavily. It’s still very good at identifying known remote access trojans (RATs), and being a configuration point by which human analysts can apply control. We looked at only a small sample of different IDS evasion strategies, and when those hopefully begin to grasp the problem and then possibly a solution. There’s a smarter way to perform detection that doesn’t rely on the IDS signature lifecycle; by collecting data on everything, and allowing offline analysis apply genius algorithms to enhance the data, enabling AI to connect the dots for us.