<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=2180921&amp;fmt=gif">

Uncovered with Stamus Security Platform: Raiz0WorM

In this series of articles we share hands-on experience from active hunts in the real world. We share details on our discovery process, how we automate workflows, and how we enable the security operations team to quickly and easily transfer knowledge afterwards with just a few simple clicks. In today's article, we will walk you through the process we used to locate an instance of Raiz0WorM on the network. 

In the case of network-based threat detection and response, security practitioners are constantly plagued by several recurring issues: a large volume of security events and logs, understaffed IT departments, expert security resource starvation, and more false positives than legitimate alerts. Because of these issues, professionals seek more advanced automation and continued innovation using novel techniques to compensate for current inefficient processes.

Without a doubt, automation is not just an added benefit to a network detection and response (NDR) system, but a necessity; however, there are cases where human intervention is required. 

For example, some of those cases require confirmation of a more expert level analyst (Tier 2 or 3) to confirm a false positive or negative. Additionally, knowledge transfer is often a problem as it requires experienced staff to dedicate time and effort to train and educate less experienced cyber defenders. Due to other priorities, experienced personnel are finding less time to engage in proactive hunting or other hands-on projects. When knowledge transfer and training of new employees is added into the mix, it’s no wonder that senior analysts feel like there aren’t enough hours in the day.

Bottlenecks often result from increases in manual repetitiveness of routines, not enough automation, and poorly integrated tools and environments. What is generally lacking (in our experience) is the ability to turn an idea into an automated process, trust that process to function as planned in the future, and then move on to the next hunt. 

This is precisely what happened during the particular hunt I describe below.

The setup

This example is a large deployment featuring specific applications for knowledge transfer, training, and hunting.

Stamus Security Platform

The Stamus Security Platform detection is deployed on Stamus Network Probe seeing 40Gbps of traffic. The customer is set up with a full Stamus NDR license that provides for a number of automated detections including:

  • Encrypted traffic analysis
  • Machine Learning enabled TLS flow beaconing detection
  • Homoglyph detection
  • HostID fingerprinting (with no local agents installed)
  • Signatures
  • Threat Intelligence feeds
  • Stamus Sightings (previously unseen communications)
  • Active Hunt Filters

Status at the beginning of the hunt

This example is a well tuned environment, but we still had about 12.5 million alerts plus 1 billion network events (protocol logs and flows) to evaluate daily.

Alert Count: 12.5 Million in the threat hunting of Raiz0WorM.


When the Stamus Security Platform was first deployed, a number of threats were immediately discovered. Thanks to full restAPI and automated detection, incident response processes started automatically and populated with contextual information while also automatically notifying the on-duty SOC team members through Rocket Chat. 

That process was already set up and completed with the integrations working as part of the Stamus Security Platform application. However, there was much more to discover...


As someone who often wishes to know what else is out there that isn’t actively being displayed, I decided to explore some active hunting angles. Often enough, active hunting is about trying to flush out False Positives vs False Negatives based on event types, metadata, and ideas or formulas for the hunt. Fortunately for me, the Stamus Security Platform’s hunting interface gives me the possibility to take an abstract layer approach and not depend on specific signature/rule/ip/domain/JA3 hash/url, etc. By taking a “just show me what I’m looking for approach” I was able to let the tool function as intended to do its job.

The Hunt

15 minutes to discovery and automation

It was early in the morning when I began this hunt, and as a result I was running short on creative ideas. Thankfully I was able to use some of the predefined threat hunting filters made available in the Enriched Hunting interface.

over 100 predefined filter sets for threat hunting to assist in locating malicious software such as Raiz0WorM

As I was going through the filters, I realized it might be worthwhile to check out the metadata we have in the Hunting interface GUI for base64 encoding and decoding functions regardless of alert types. The only thing I was interested in was simple http requests/responses that had usage of base64 functions and those with http status codes 200.

With just two clicks I was able to set 2 new active filters.

The results narrowed down the number of events from 12.5 million to just 10. Then I noticed a sequence of suspicious URLs and user agents combined with payloads (de)obfuscation. 

Narrowed down results in the hunt for Raiz0WorM

a closer look at the HTTP information in the hunting of Raiz0WorM

Part of the full transaction metadata:

The full transaction metadata from the hunt for Raiz0WorM

Here we can see a clear reference to Raiz0WorM and base64 function usage that translates as:
A reference to Raiz0WorM is located on the network

A specific sequence of URLs and user agents:

specific urls and useragents are seen in the hunt for Raiz0WorM

Source IPs are seen in the hunt for Raiz0WorM

Seeing this gave me more contextual information, leading me to narrow down the filter even further: 

Additional filters are applied in the hunt for Raiz0WorM

Upon regular IP and domain checks, it was also confirmed that this communication is not expected, nor is it part of any vulnerability scan or testing.

The IP address is analyzed to investigate the instance of Raiz0WorM

The IP address is analyzed to investigate the instance of Raiz0WorM

This discovery led me to the obvious need to raise an incident response (IR). However, I wanted to achieve 3 more goals:

  1. 1. Document and transfer the knowledge and experience I had just accumulated.
  2. 2. Fully automate the job and raise another incident if needed without any of my colleagues or myself needing to spend time doing it manually in the future.
  3. 3. Raise IRs for any such occurrences in the past (specifically within the last 60 days)


I wanted to automate the process I had just completed so I would not need to repeat it in the future, ultimately freeing up my time to conduct other hunts.

Knowledge Transfer and Automation

A few more clicks in the Enriched Hunting interface allowed me to translate the hunting idea I had into an automated process. I also wanted to utilize webhooks and restAPI to automatically populate IR escalation into existing SOC environments/chat notification systems and SOAR solutions. What I wanted was achieved with a few clicks via the Policy Action menu via the Create STR Event (we now call this a “Declaration of Compromise”) option:

Creating an STR event in the Raiz0WorM hunt

I filled in the details specifying attackers and victims while notating any extra information that was available and relevant.

Now any and all logs, doc links, contextual data, incident response tickets, and chat notifications were automated via existing integrations into the standard organization’s process and tools (SIEMs for example).

The details of the STR event are filled in the hunt for Raiz0WorM


Going from a hypothetical hunting idea to the creation of an automated classification and triage process is valuable on its own, but the job is only half done. Usually, your colleagues need additional information to understand what you’ve done, why you’ve done it, and how they can repeat the process or learn from it. The ability to combine the current security team’s knowledge with the provided visibility of the environment and integrate that combination into an existing process or tool for knowledge will serve IT professionals well as they continue to defend their organizations from threats. As you can see in the Raiz0WorM example, this process is made simple with the Stamus Security Platform. 

More Information

Hopefully this gives you a taste of how the Stamus Security Platform can help security teams know more, respond sooner, and mitigate the risk to their organizations.

To read more articles in this series, check out these "Uncovered with Stamus Security Platform" blogs:

And if you’d like to see Stamus Security Platform in action, please click on the link below to schedule a live demonstration.

Peter Manev

Peter Manev is the co-founder and chief strategy officer (CSO) at Stamus Networks. He is a member of the executive team at Open Network Security Foundation (OISF). Peter has over 15 years of experience in the IT industry, including enterprise-level IT security practice. He is a passionate user, developer, and explorer of innovative open-source security software, and he is responsible for training as well as quality assurance and testing on the development team of Suricata – the open-source threat detection engine. Peter is a regular speaker and educator on open-source security, threat hunting, and network security at conferences and live-fire cyber exercises, such as Crossed Swords, DeepSec, Troopers, DefCon, RSA, Suricon, SharkFest, and others. Peter resides in Gothenburg, Sweden.

Schedule a Demo of Stamus Security Platform


Related posts

Uncovered with Stamus Security Platform: Tapped on the Shoulder

In this series of articles, we explore a set of use cases that we have encountered in real-world...

In the Trenches with NDR: NDR Discovers Crypto Wallet Stealer on U.S. University's Network

Tl:DR: A Large U.S. university lacked sufficient visibility into a large segment of its environment...