phonemenal is a phonetic similarity and homophone detection library for Python. It is designed for identifying sound-alike collisions across namespaces - package registries, domains, social handles, and anywhere else that a name spoken aloud could be confused for another. The docs can be found at br0k3nlab.com/phonemenal and the source at GitHub .

Some background

This project has roots going back to 2016. During a local SOC training exercise, a parody domain was registered - a catch-all email address was set up to forward to a personal inbox. Almost immediately, sensitive information started flowing in. Real credentials. Real documents. People were typing what they heard or remembered, and the spelling didn’t match up.

That accidental discovery became a mutual research interest between myself and Reagan Short . We spent time digging into the problem space, exploring linguistic patterns, and ultimately presented our findings at TROOPERS 2023 under the title Homophonic Collisions: Hold me Closer Tony Danza. You can watch the full talk here or grab the slides .

The core of the research was this: existing defenses focus on what words look like (typosquatting, homoglyphs), but largely ignore what words sound like. Tools like DNSTwist are great for visual permutations, but they don’t account for the fact that “phlask” and “flask” are pronounced identically, or that someone dictating “numpy” over the phone could easily end up with “numpie” on the other end.

phonemenal is the tooling that grew out of that research.

The problem: homophonic collisions

A homophonic collision occurs when two distinct strings share the same (or nearly the same) pronunciation. There are a few levels to this:

1. Exact homophones - words that are phonetically identical: blue / blew, right / write, new / knew
2. Near-homophones - words that are phonetically very close: crowd / crown, page / rage, elastic / fantastic
3. Soundsquatting - the weaponized exploitation of homophonic collisions for malicious purposes

The diagram below illustrates just how many points of failure exist in the communication chain - from the speaker’s intended message to the listener’s interpretation. Every one of these is a potential collision point.

Coils of Communication Chaos - adapted from the UW Linguistics Research Guide

That last one is where it gets interesting from a security perspective. If an attacker registers numpie on PyPI, or walmaret.com as a domain, or phlask as a package name - these are not typos. They are phonetically equivalent names designed to exploit the gap between what we hear and what we type.

During our research, we found real-world examples across multiple namespaces:

• Domains (from the Alexa top 1000): walmaret.com, yootube.com, webbex.com, wellesfarago.com
• PyPI packages: soundsquat variants of popular packages, some validated as malicious
• Voice assistants and LLMs: speech-to-text and text-to-speech wrappers that silently introduce collision errors

The attack surface grows every time a human speaks a name and someone else types it. And with voice assistants and LLM integrations becoming increasingly prevalent, the risk surface is expanding.

See it in action

The explorer below shows pre-computed phonetic breakdowns for real examples across different categories. Click any pair to expand the phoneme details. Pay attention to the Package Squats and Domain Squats tabs - these are the kinds of collisions phonemenal is built to detect.

How phonemenal works

The library provides three complementary scoring algorithms, all normalized to a 0.0–1.0 range:

PPC-A (Positional Phoneme Correlation - Absolute) builds positional phoneme combinations by traversing forward and reverse directions with padding, then measures set intersection. It captures how much of the positional phoneme structure two words share.

PLD (Phoneme Levenshtein Distance) operates at the syllable level, using CMU dict stress markers to split phonemes into syllable groups. Each syllable is an atomic unit, so the distance reflects how many whole syllables differ - this is closer to how we actually perceive speech.

LCS (Longest Common Subsequence) computes the ratio of the longest common subsequence to the total sequence length. Simple, effective, and robust to insertions.

A composite score combines all three with configurable weights.

For words not in the CMU Pronouncing Dictionary (think: brand names, neologisms, package names like numpy or pytorch), phonemenal uses a fallback encoder - a simplified Metaphone-inspired encoding that applies digraph replacement, vowel normalization, and character collapsing to produce phonetic keys. Sound-alike names produce the same or similar keys.

from phonemenal import fallback

fallback.phonetic_key("numpy")    # → "nAmpY"
fallback.phonetic_key("numpie")   # → "nAmpY"  - exact match

fallback.phonetic_key("flask")    # → "flAsk"
fallback.phonetic_key("phlask")   # → "flAsk"  - exact match

fallback.phonetic_key("phone")    # → "fAn"
fallback.phonetic_key("fone")     # → "fAn"    - exact match

Getting started

pip install phonemenal

# With LLM support for deep analysis
pip install phonemenal[llm]

The API is intentionally straightforward. Here are the core operations:

from phonemenal import similarity, homophones, variants, splitting, scanning

# -- Similarity scoring (all 0.0–1.0) --
similarity.ppc("crowd", "crown")         # PPC-A score
similarity.pld("elastic", "fantastic")   # syllable-level edit distance
similarity.lcs("packaging", "packages")  # longest common subsequence
similarity.composite("crowd", "crown")   # weighted average of all three

# -- Exact homophones --
homophones.find("blue")        # → ["blew"]
homophones.find("right")       # → ["rite", "wright", "write"]

# -- Near-homophones --
homophones.find_similar(
    "crowd",
    candidates=["crown", "crowed", "crude"],
    min_score=0.7
)

# -- Variant generation --
variants.generate("flask")                # → {"phlask", "flazk", ...}
variants.generate_morphological("click")  # → {"clicked", "clicker", "clicks", ...}

# -- Compound word splitting --
splitting.split("bluevoyage")                 # → ["blue", "voyage"]
splitting.homophone_permutations("bluevoyage") # → ["bluevoyage", "blewvoyage", ...]

The CLI

phonemenal ships with a CLI that uses Rich for formatted output:

# Compare two words across all algorithms
phonemenal similarity crowd crown

# Specific algorithm
phonemenal similarity crowd crown -a ppc

# Find exact homophones
phonemenal homophones blue

# Generate sound-alike variants
phonemenal variants flask -m  # include morphological variants

# Split compound words and show permutations
phonemenal split bluevoyage -p

# Full comparison report
phonemenal compare crowd crown

# JSON output for scripting
phonemenal compare crowd crown -j

Scanning at scale

The real power shows up when you need to check names against a known set. The scanning pipeline combines forward matching, variant generation, and optional reverse verification:

from phonemenal.scanning import scan, scan_with_reverse, format_matches

# Forward scan: check candidates against known names
matches = scan(
    candidates=["numpie", "phlask", "klik"],
    known_names=["numpy", "flask", "click"],
    threshold=0.75
)

print(format_matches(matches))
# [!!!] 'numpie' ~ 'numpy'   (score: 1.00, type: exact_phonetic, keys: nAmpY / nAmpY)
# [!!!] 'phlask' ~ 'flask'   (score: 1.00, type: exact_phonetic, keys: flAsk / flAsk)
# [!!!] 'klik'   ~ 'click'   (score: 1.00, type: exact_phonetic, keys: klAk / klAk)

For reverse scanning, you can provide a lookup function to check if generated variants actually exist in the wild:

import httpx

def check_pypi(name: str) -> bool:
    """Check if a package exists on PyPI."""
    resp = httpx.head(f"https://pypi.org/project/{name}/", follow_redirects=True)
    return resp.status_code == 200

matches = scan_with_reverse(
    candidates=["numpy"],
    known_names=["numpy"],
    exists_fn=check_pypi,
    threshold=0.75,
    include_morphological=True
)

This is where it starts to get practical for real defensive operations - monitoring package registries, domain registrations, or any namespace where soundsquatting could be a vector.

LLM-powered deep analysis

For cases where algorithmic scoring is ambiguous, phonemenal supports optional LLM-powered analysis. It can break down syllables, generate IPA transcriptions, and score using a weighted phonetic model:

# Anthropic API
phonemenal analyze numpy --provider anthropic

# OpenAI API
phonemenal analyze numpy --provider openai

The LLM integration over API / remote models is entirely optional - the core library has zero external API dependencies. Instead, you can pass the analysis off to a local agent from within phonemenal, or just handoff the prompt. The benefit of this approach is it is built into the core library, with no extras or auth requirements.

# Pipe to a local agent
phonemenal analyze numpy --agent claude

# Just get the prompt (for piping to your own workflow)
phonemenal prompt numpy | pbcopy

Real-world validation: scanning known malicious packages

While building out a supply chain monitoring and analysis framework, I integrated homophonic collision detection into the process. It was then that I decided to dust off the POCs from our research and release the phonemenal library.

To further put this to the test, I ran phonemenal against the DataDog Malicious Software Packages Dataset - a curated collection of known malicious packages from PyPI and npm (credit to DataDog for maintaining this dataset). The goal was simple: scan the names of known malicious packages against popular legitimate packages to see how many are phonetically similar - potential soundsquats hiding in plain sight.

NOTE: only the package names from the manifest were used in this analysis. The actual malicious samples were not downloaded or executed.

PyPI results

1,786 known malicious package names scanned against the top ~125 most popular PyPI packages:

56.9% of the malicious packages had at least one phonetic match (>= 0.60) against a popular package. At the strictest threshold (exact phonetic key match), 11 packages were dead ringers:

The requests library alone had 20+ phonetically similar malicious variants in the dataset - everything from simple transpositions (reuquests, requesrts) to onset substitutions (fequests, dequests, tequests).

npm results

9,505 known malicious package names scanned against ~120 popular npm packages:

38.4% of the malicious set had phonetic matches. The 3 exact hits:

The typescript package was a particularly heavy target with 15+ versioned squats (typescript-5.5, typescript-5.6, typescript-go, etc.).

Here is what a real scan against the DataDog dataset looks like in practice:

import json
import httpx
from phonemenal.scanning import scan, format_matches

# Load malicious package names from DataDog manifest (names only!)
resp = httpx.get(
    "https://raw.githubusercontent.com/DataDog/"
    "malicious-software-packages-dataset/main/samples/pypi/manifest.json"
)
malicious_names = list(resp.json().keys())

# Scan against popular packages
popular = ["requests", "flask", "numpy", "django", "selenium", "colorama",
           "beautifulsoup4", "aiohttp", "botocore", "cryptography"]

matches = scan(candidates=malicious_names, known_names=popular, threshold=0.80)
print(format_matches(matches))

These are not hypothetical results. These are real malicious packages, confirmed by DataDog’s GuardDog analysis, that phonemenal correctly flags as phonetically suspicious.

What’s next?

As I mentioned above, I am integrating it into a supply chain monitoring framework at the moment, but there are lots of other use cases for detecting and preventing sound as an attack vector, especially with voice assistants coming back into popularity as part of the genAI craze.

phonemenal is still early and there is more to explore. Acoustic analysis approaches, dialect-aware detection, expanded namespace coverage, and deeper integration with package registry monitoring are all on the horizon.

If this is a problem space that interests you, check out the docs , the repo , or the TROOPERS talk for the full research background. Contributions and ideas are welcome.

The REx project is a collection and breakdown of several of the most popular open security detection rules for analysis and exploration, enabled by the powerful search and visualization capabilities of the Elastic stack! The docs can be found at rulexplorer.io .

The Detection Engineering Threat Report (DETR) is the visual component of the REx project, where the data speaks for itself, with minimal interpretive narration.

What is the purpose of the REx project?

This project provides a mechanism for interacting with various popular rule sets , in order to have a better understanding of the detection landscape, and quickly survey and compare multiple approaches.

Insights can be derived from data by looking at it from different perspectives, especially when done in a visual manner. The idea of this project is to view rule development, the detection engineering ecosystem, and the threat landscape from alternative lenses.

What is the Detection Engineering Threat Report (DETR)?

And why call it a report? It was organized and structured to be consumed as a report, albeit, an interactive and dynamic report.

Like many in the industry, we constantly review and consume the various threat reports published by different vendors and projects. The normal flow for how the data is produced for these reports can be seen below. It is usually (at least in part) an aggregation and analysis of observed alerts and raw events within each respective environment or purview.

It is no secret that these reports and data are prone to confirmation bias, or authors over-focusing on their own assumptions or sources of information. Additionally, we are also aware of the risk of a feedback loop, where we see primarily what we look for, only, it is often overly-reinforced because we then consume information from other reports based on their own observations. This can be described as a threat detection observation paradox and can be seen below.

I think the industry does a pretty good job of controlling these biases, assumptions, and tendencies, so this is not meant to be critical of any approach. The idea is to attempt to ascertain additional perspective by peering into the process at a different point in the cycle. Focusing on threats through detection engineering efforts (rules), rather than from the triage and analysis (alerts).

It is not a uniquely discrete perspective, as these cannot exist without each other, just a shift up the spectrum.

As of this release, the DETR consists of the following sections:

State of current detections

This section analyzes the latest snapshot of all covered rule sets. The rule snapshots are refreshed every 24 hours, which is why they do not have a timestamp associated with them.

Developments and changes over time

This section analyzes the changes made to all of covered rule sets. Insights into where the most development takes place per individual rule attribute, including maintenance perspectives.

The four types of unique changes (new terms) are:

• new detection logic fields detected over last 30d
• new detection logic fields by author detected over last 30d
• new techniques detected over last 30d
• new techniques by author detected over last 30d

Uniqueness over time

This section analyzes the uniqueness of detection logic fields and ATT&CK techniques within rules over time. It can be reflective of novelty, new datasources, or even just schemas that are too large.

Emerging threats analysis

This dashboard analyzes the reactiveness and responsiveness to known major threats, CVEs, or any other prominently discussed risks.

What is interesting and insightful to be observed here is the fact that most rule detection logic approaches tend to focus on behavioral aspects, as opposed to being too atomic or overly specific and signature-like. This means that some insights to coverage may not be immediately obvious, or in other words, successful pre-existing detection capabilities for major emerging threats can easily be overlooked when inspecting from a purely rules perspective (as opposed to alerts).

The CVE’s chosen were the most represented in other threat reports. While they are insightful in themselves, they are also meant to showcase the process of temporal analysis - simply look up the timing of other CVE’s or events and compare accordingly.

What’s the goal?

Put simply, the goal is to provide a platform to easily analyze rules and the detection engineering ecosystem in new ways.

It may be helpful to think about the following personas when using this project:

• Security Analysts
• Threat Hunters
• Security Engineers
• Security Researchers
• Security Managers

Additionally, consider the following use cases:

• Rule Development Lifecycle
• Threat Landscape Analysis
• Maintenance Costs
• Threat Coverage
• Data Sources and Field usage

There are multiple ways to search and visualize the data, depending on specific need or perspective. To maximize insights and perspective, it is all about filtering and pivoting. Whether starting with a search in Discover or any of the dashboards as part of the DETR, you can filter down around observations or known events, such as the release of a CVE or exploit.

This is not meant to be a vendor or coverage comparison tool! Leave that to Gartner and Mitre. Coverage is a complex thing and each source has their own approaches and philosophies, which are better debated elsewhere. More rules does not always translate to more or better coverage.

For insights into creating high-quality, high-efficacy rules, check out the Zen of Security Rules.

Details

The data consists of:

• a snapshot of each respective repo’s primary branch
• all new and changed rule files over time
• unique techniques and fields from the detection logic

Every 24 hours, the latest snapshot of the rules in their primary repos is saved. Additionally, all modifications to rules over that time period is also saved within a different index. Finally, search results of unique techniques and fields over a 30 day period are also saved. The details of the schema, indexes, and data can be found in the schema docs . The rule logic is also parsed for additional in depth field analysis.

The Kibana features provided include:

Search

Visualize

Graph

Refreshed every 24 hours

Similar to the LoFP project, this is meant to be a maintenance-free project, and so the data remains fresh and auto-updates every 24 hours

Limitations?

As of this date, support for correlation Sigma rules still needs to be added.

The farm is growing! A new way to live off the land, in this case, by blending in with it.

What is LoFP?

Living off the False Positive is an autogenerated collection of false positives sourced from some of the most popular rule sets. The information is categorized along with ATT&CK techniques, rule source, and data source. Entries include details from related rules along with their description and detection logic.

What’s the goal?

The goal is to enable both red and blue teams with this information.

Red teams can use this information to blend in by mimicking or looking similar to the FP activity. Alert fatigue often causes analysts to readily ignore things even remotely false positive. At there very least, it will instill doubt.

Blue teams on the other hand, can use this information to assess weak spots in their detection logic. They can also compare across rule sets to see if it is a broad tendency, or maybe something more specific to a particular vendor. It can also assist during alert triage and investigation, by looking at common FPs around certain techniques and data sources.

Details

For now, it encompasses rules from the following sources:

• elastic detection rules
• sigma rules
• splunk rules

And it isn’t all the rule directories at this point, but this could expand. The trouble is, false positive annotations tend to be more narrative than keyword based, making it difficult to aggregate similarities.

This is why you shouldn’t use this by just scrolling along – that would be a little painful. Instead, focus on searching for keywords in the false positives themselves (such as “python”, “powershell”, etc.), the techniques, rule source, or data source as a starting point.

If you know you will be leveraging certain techniques, find similar ones and see what the false positives trends tend to look like and use this information to blend in.

As you can see, the idea is to include certain key details of the source from the rule(s) that the FPs come from to maximize the value of the information.

Checkout the repo for more details on auto generation.

Nightly builds

This is meant to be a maintenance-free project. As a result, this data refreshes nightly, based on the latest available updates in the respective repos.

Future expansion?

Possibly, but let’s see how this goes first.

The most difficult challenge with RMM detection is contextual awareness around usage to determine if it is valid or malicious.

• if the software is not used in the environment
  • could it be legitimate by a random employee?
  • is it an attacker BYOL
  • even so, all occurrences could probably be considered suspicious
• if it is used in the environment
  • is every use of it legitimate? Probably not
  • this also creates significant living off the land (LOL) opportunity
  • some occurrences should be considered suspicious
• without any contextual awareness, this is an even harder problem

Under resources, there is a table of known RMM executables, as well as a raw json RMM.json for processing.

Approaches to detecting

A. Explicitly defined RMM software + behavioral (less resilient)

These rely on explicity referencing known RMM artifacts (in some way) within the logic

1. Known RMMs
2. Known RMM + low prevalence
3. New executable in environment + known RMM
4. New + RMM + suspicious activity
5. New + RMM + alert

B. Dynamically and generically defining RMM + behavioral

This relies completely on common behaviors of RMM (can misidentify)

1. Logic for generic RMM behaviors (vs pre-defined known RMMs)

Details

A1. Known RMMs

Two options to defining known RMM’s

Option 1: comprehensive list of identified RMM executables

Simply build a list of all known executables (see the table below). This is brittle, but more precise

process where event.type == "start" and
(
  // Windows
  (
    host.os.type == "windows" and
      process.executable : (
        "C:\\Program Files*\\*\\NinjaRMMAgentPatcher.exe",
        "C:\\Program Files*\\NinjaRMMAgent\\NinjaRMMAgentPatcher.exe",
        "C:\\ProgramData\\NinjaRMMAgent\\ninjarmm-cli.exe",
        "C:\\Program Files*\\*\\NinjaRMMAgent.exe",
        "C:\\Program Files*\\NinjaRMMAgent\\NinjaRMMAgent.exe",
        
        "C:\\Program Files*\\ATERA Networks\\AteraAgent\\AteraAgent.exe",
        "C:\\Program Files*\\ATERA Networks\\AteraAgent\\Packages\\AgentPackageNetworkDiscoveryWG\\AgentPackageNetworkDiscoveryWG.exe",
        "C:\\Program Files*\\ATERA Networks\\AteraAgent\\Packages\\AgentPackageAgentInformation\\AgentPackageAgentInformation.exe",
        "C:\\Program Files*\\ATERA Networks\\AteraAgent\\Packages\\AgentPackageSTRemote\\AgentPackageSTRemote.exe",
        "C:\\Program Files*\\ATERA Networks\\AteraAgent\\Packages\\AgentPackageFileExplorer\\AgentPackageFileExplorer.exe",
        "C:\\Program Files*\\ATERA Networks\\AteraAgent\\Packages\\AgentPackageMonitoring\\AgentPackageMonitoring.exe",
        "C:\\Program Files*\\ATERA Networks\\AteraAgent\\Packages\\AgentPackageRuntimeInstaller\\AgentPackageRuntimeInstaller.exe",
        
        "C:\\Windows\\SysWOW64\\config\\systemprofile\\AppData\\Local\\GoToAssist Remote Support Applet\\*.tmp\\GoToAssistService.exe",
        "C:\\Users\\*\\AppData\\Local\\GoToAssist Remote Support Applet\\*.tmp\\GoToAssistProcessChecker.exe",
        "C:\\Program Files*\\LogMeIn\\GoToAssist Corporate\\*\\G2AC_HostLauncher.exe",
        "C:\\Program Files*\\GoToMeeting\\*\\G2MInstaller.exe",
        "C:\\Users\\*\\AppData\\Local\\GoToMeeting\\*\\g2mcomm.exe",
        "C:\\Users\\*\\AppData\\Local\\GoToMeeting\\*\\g2mlauncher.exe",
        "C:\\Program Files*\\GoToAssist Remote Support Customer\\*\\g2ax_host_service.exe",
        "C:\\Program Files*\\GoToAssist Remote Support Customer\\*\\g2ax_comm_customer.exe",
        "C:\\Users\\*\\AppData\\Local\\GoTo Resolve Applet\\*.tmp\\GoToResolveService.exe",
        "C:\\Program Files*\\GoToAssist Remote Support Unattended\\*\\GoToAssistTools64.exe",
        "C:\\Program Files*\\GoToAssist Remote Support Unattended\\*\\GoToAssistUnattended.exe",
        "C:\\Users\\*\\AppData\\Local\\goto-updater\\pending\\GoToSetup-*.exe",
        "C:\\Program Files*\\GoToMeeting\\*\\g2mlauncher.exe",
        "C:\\Users\\*\\AppData\\Local\\GoToAssist Remote Support Applet\\*.tmp\\GoToAssistCrashHandler.exe",
        "C:\\Users\\*\\AppData\\Local\\GoToMeeting\\*\\g2mupdate.exe",
        
        "C:\\ManageEngine\\DesktopCentralMSP_Server\\jre\\bin\\java.exe",
        "C:\\ManageEngine\\ADManager Plus\\jre\\bin\\java.exe",
        "C:\\Program Files*\\ManageEngine\\PMP\\tools\\archiver\\windows\\x86-64\\7za.exe",
        "C:\\ManageEngine\\elasticsearch\\jre\\bin\\java.exe",
        "C:\\Program Files*\\ManageEngine\\PMP\\jre\\bin\\java.exe",
        "C:\\Program Files*\\ManageEngine\\ServiceDesk\\DesktopCentral_Server\\bin\\7za.exe",
        "C:\\Program Files*\\ManageEngine\\ServiceDesk\\DesktopCentral_Server\\bin\\wrapper.exe",
        "C:\\ManageEngine\\OpManager\\jre\\bin\\java.exe",
        "C:\\ManageEngine\\EventLog Analyzer\\jre\\bin\\java.exe",
        "C:\\ManageEngine\\ADAudit Plus\\pgsql\\bin\\postgres.exe",
        "C:\\ManageEngine\\OpManager\\Probe\\OpManagerProbe\\pgsql\\bin\\postgres.exe",
        
        "C:\\Program Files*\\Microsoft Intune Management Extension\\ClientHealthEval.exe",
        "C:\\Program Files*\\WindowsApps\\Microsoft.*\\IntuneManagementExtensionBridge\\IntuneManagementExtensionBridge.exe",
        "C:\\Program Files*\\WindowsApps\\Microsoft.*\\BridgeLauncher\\BridgeLauncher.exe",
        "C:\\Program Files*\\Microsoft Intune Management Extension\\Microsoft.Management.Services.IntuneWindowsAgent.exe",
        "C:\\Program Files*\\Microsoft Intune Management Extension\\Microsoft.Management.Clients.CopyAgentCatalog.exe",
        "C:\\Program Files*\\Microsoft Intune Management Extension\\SensorLogonTask.exe",
        "C:\\Program Files*\\Microsoft Intune Management Extension\\AgentExecutor.exe",

        "C:\\Users\\*\\AppData\\Local\\MSP Anywhere for N-central\\Viewer\\Tmp\\SWI_MSP_RC_ViewerUpdate-*.exe",

        "C:\\Program Files*\\DesktopCentral_Agent\\bin\\dcagentservice.exe",
        "C:\\Program Files*\\DesktopCentral_Agent\\bin\\DCFAService64.exe",
        "C:\\Program Files*\\DesktopCentral_Agent\\bin\\dcagentregister.exe",
        "C:\\Program Files*\\DesktopCentral_Server\\pgsql\\bin\\postgres.exe",
        "C:\\Program Files*\\DesktopCentral_Server\\bin\\wrapper.exe",
        "C:\\ManageEngine\\DesktopCentral_Server\\bin\\wrapper.exe",
        "C:\\Program Files*\\DesktopCentral_Server\\bin\\UEMS.exe",
        "C:\\Program Files*\\DesktopCentral_Server\\nginx\\dcnginx.exe",
        "C:\\Program Files*\\ManageEngine\\ServiceDesk\\DesktopCentral_Server\\jre\\bin\\java.exe",
        "C:\\Program Files*\\DesktopCentral_Agent\\bin\\EMSAddonInstaller.exe",
        "C:\\ManageEngine\\DesktopCentral_Server\\jre\\bin\\java.exe",
        "C:\\Program Files*\\DesktopCentral_Server\\apache\\bin\\dcserverhttpd.exe",
        "C:\\Program Files*\\DesktopCentral_Server\\bin\\7za.exe",
        "C:\\Program Files*\\DesktopCentral_Server\\jre\\bin\\java.exe",
        "C:\\Program Files*\\DesktopCentral_Server\\bin\\dcnotificationserver.exe",
        "C:\\Program Files*\\DesktopCentral_Agent\\dcconfig.exe",
        "C:\\Program Files*\\DesktopCentral_Agent\\patches\\*-gimp-*-setup.exe",
        "C:\\ManageEngine\\AssetExplorer\\DesktopCentral_Server\\bin\\wrapper.exe",
        "C:\\Program Files*\\ManageEngine\\ServiceDesk\\DesktopCentral_Server\\lib\\native\\64bit\\wrapper.dll",
        "C:\\Program Files*\\ManageEngine\\ServiceDesk\\DesktopCentral_Server\\jre\\bin\\awt.dll",
        "C:\\Program Files*\\ManageEngine\\ServiceDesk\\DesktopCentral_Server\\jre\\bin\\sunec.dll",
        "C:\\Program Files*\\ManageEngine\\ServiceDesk\\DesktopCentral_Server\\jre\\bin\\freetype.dll",
        "C:\\Program Files*\\ManageEngine\\ServiceDesk\\DesktopCentral_Server\\jre\\bin\\fontmanager.dll",
        "C:\\Program Files*\\ManageEngine\\ServiceDesk\\DesktopCentral_Server\\lib\\native\\64bit\\SyMNative.dll",
        "C:\\Program Files*\\ManageEngine\\ServiceDesk\\DesktopCentral_Server\\lib\\native\\64bit\\OSDSyMNative.dll",
        
        "C:\\Windows\\Action1\\action1_remote.exe",
        "C:\\Windows\\Action1\\action1_agent.exe")
  ) or

  // MacOS
  (
    host.os.type == "macos" and
      process.executable : (
        "/Applications/NinjaRMMAgent/programfiles/ninjarmm-macagent",

        "/Applications/GoToMeeting.app/Contents/MacOS/GoToMeeting",
        "/Applications/GoToMeeting.app/Contents/Helpers/G2MUpdate",
        "/Users/*/Library/Application Support/LogMeInInc/GoToMeeting/G2MUpdate",
        
        "/Library/Intune/Microsoft Intune Agent.app/Contents/MacOS/IntuneMdmDaemon",

        "/Applications/MSP Anywhere Agent N-central.app/Contents/Resources/MSP Anywhere Service Configurator.app/Contents/MacOS/MSP Anywhere Service Configurator",
        "/Applications/MSP Anywhere Agent N-central.app/Contents/Resources/MSP Anywhere Helper")
  )
)

Option 2: resilient patterns of known RMM software

This is a more resilient approach, which looks for

• unique patterns of the executable path
• code signature unique to RMM software

any where event.category : ("process", "library") and event.type == "start" and
(
  // Windows
  (
    host.os.type == "windows" and (
      process.executable : ("?:\\*NinjaRMMAgent*.exe",
                            "?:\\*\\AteraAgent\\*.exe",
                            "?:\\*\\GoToAssist*\\*.exe", "?:\\*\\GoToMeeting\\*.exe", "?:\\*\\GoTo*.exe", "?:\\*\\GoToSetup*.exe",
                            "?:\\*ManageEngine\\*.exe",
                            "?:\\Microsoft Intune*\\*.exe", "?:\\IntuneManagement*\\*.exe",
                            "?:\\*\\*N-central*\\*.exe",
                            "?:\\*\\DesktopCentral*\\*.exe",
                            "?:\\*\\Action1\\*.exe") or
      dll.path : ("?:\\*NinjaRMMAgent*.dll",
                  "?:\\*\\AteraAgent\\*.dll",
                  "?:\\*\\GoToAssist*\\*.dll", "?:\\*\\GoToMeeting\\*.dll", "?:\\*\\GoTo*.dll", "?:\\*\\GoToSetup*.dll",
                  "?:\\*ManageEngine\\*.dll",
                  "?:\\Microsoft Intune*\\*.dll", "?:\\IntuneManagement*\\*.dll",
                  "?:\\*\\*N-central*\\*.dll",
                  "?:\\*\\DesktopCentral*\\*.dll",
                  "?:\\*\\Action1\\*.dll") or
      process.code_signature.subject_name : ("NinjaRMM, LLC",
                                             "Atera Networks Ltd",
                                             "LogMeIn, Inc.",
                                             "ZOHO Corporation Private Limited",  // could FP due to non-RMM software
                                             "Action1 Corporation") or
      dll.code_signature.subject_name : ("NinjaRMM, LLC",
                                         "Atera Networks Ltd",
                                         "LogMeIn, Inc.",
                                         "ZOHO Corporation Private Limited",  // could FP due to non-RMM software
                                         "Action1 Corporation")
    )
  ) or

  // MacOS
  (
    host.os.type == "macos" and (
      process.executable : ("/Applications/*NinjaRMMAgent/*",
                            "/Applications/*GoToMeeting*/*", "/Users/*/Library/*/GoToMeeting*/*",
                            "/Library/*Microsoft InTune*/*", "/Users/*/Library/*Microsoft InTune*/*",
                            "/Applications/*N-central*/*") or

      // or dll.path : () or
      // process.code_signature.subject_name : () or
      // dll.code_signature.subject_name : ()
    )
  )

  // Linux
)

A2. Known RMM + low prevalence

Perform one of the searches from step 1 and aggregate on:

• hosts
• users
• unique executions

Look for low counts

A3. New executable in environment + known RMM

Create a new terms stlye rule based on step 1

• window history of now-30d
• base the new terms on: process.name, host.id (remove host.id for full environment prevalence)

If you do not have a new terms capability, you can perform the search in step 1 to build a list of observed RMM executables, then pivot (or join) on a search for recent exections.

A4. New executable + known RMM + suspicious activity

Combine step 3 with subsequent suspicious activity (such as lateral movement information gathering).

With Elastic, you could do this by:

1. create the rule from step 3 (optionally as a building_block_rule to keep noise down)
2. create a separate sequence based rule that looks for the new term then the suspicious activity
   • to simplify this, you can create another building_block_rule for suspicious activity

sequence by host.id, user.id, process.name with maxspan=25m
  [alert where rule.id == <new_term_rule_step3>]
  [alert where rule.id == <suspicious_rule_step4>]

A5. New executable + known RMM + alert

Similar to step 4 except referencing actual alerts for the second part of the sequence

sequence by host.id, user.id, process.name with maxspan=25m
  [alert where rule.id == <new_term_rule_step3>]
  [alert where true]

Leaving subquery 2 generic is a great option, since a newly occurring RMM would be suspicious in this case. It can be tightened down with a few options:

• limiting query 2 to certain techniques or subtechniques
• add additional logic to query 2 from the raw alert results, or even a subset of alerts
• adding additional queries to the sequence to express a more progressed attack

B1. Logic for generic RMM behaviors

Rather than using statically defined RMM artifacts based on observations, this entails building out generic logic to identify them. This is a much greater challenge, especially due to their legitimate nature. Additional features such as ML, entity analytics, and other aggregation based searching make a significant difference here.

Once a dynamic method is defined, then steps 2-5 apply, creating a sustainable detection approach.

I think it is doable from a purely rule-based approach, but I will return to this a bit later …

Also, with the Elastic ES|QL piped language, these become much more feasible within a single rule.

Analysis of Elastic detection-rules, showing event types and field distribution per technique. The full results are represented in the file below (fields_by_technique.json)

The structure is:

"library": {                                       # event.category (generic if event.category not defined)
      "fields": {                                  # field distribution for that event.category within that technique
        "dll.code_signature.status": "100.00%",    # field with percentage
        "dll.code_signature.trusted": "100.00%",   # field with percentage
        "host.os.type": "100.00%",                 # field with percentage
        "process.pid": "100.00%"                   # field with percentage
      },
      "rule_count": 1                              # number of rules within this technique + event.category

Ex:

"T1553": {
    "generic": {
      "fields": {
        "event.provider": "100.00%",
        "host.os.type": "100.00%",
        "message": "100.00%"
      },
      "rule_count": 1
    },
    "library": {
      "fields": {
        "dll.code_signature.status": "100.00%",
        "dll.code_signature.trusted": "100.00%",
        "host.os.type": "100.00%",
        "process.pid": "100.00%"
      },
      "rule_count": 1
    },
    "process": {
      "fields": {
        "event.category": "66.67%",
        "event.type": "100.00%",
        "host.os.type": "100.00%",
        "process.args": "100.00%",
        "process.executable": "33.33%",
        "process.name": "66.67%",
        "process.parent.executable": "33.33%",
        "process.pe.original_file_name": "33.33%"
      },
      "rule_count": 3
    },
    "registry": {
      "fields": {
        "event.type": "100.00%",
        "host.os.type": "100.00%",
        "process.executable": "33.33%",
        "registry.data.strings": "66.67%",
        "registry.path": "100.00%",
        "registry.value": "33.33%"
      },
      "rule_count": 3
    }
  }

For technique T1553, the following event types were present on the specified number of rules:

• 1 generic
• 1 library
• 3 process
• 3 registry

And the respective fields per event.category were present relative to those counts as defined

Data

A full json dump of the data can be found here , where this blog was originally posted.

Happy analyzing!

The organization I have in mind when writing this is a SOC or CSIRT, in which large scale hunting via Splunk is likely to be conducted, though it can apply just about any where. It is key to be able to have relevant data sets for which to properly vet queries against. Fortunately, there are many example data sets available for testing on GitHub, from Splunk, and some mentioned below. There are also “data generators” which can generate noise for testing. Best of all would be to create your own though :).

I was fortunate to have had the enjoyable experience of participating in a Boss of the SOC CTF a few years back, which had some pretty good exemplar security related data. Earlier this year, they released the data set publicly here.

This guide is not meant to be a deep dive into the structuring of a query using the SPL. The best place for that is the Splunk documentation itself, starting with this. This is geared more towards operations in which multiple queries are written, maintained, and used in an operational capacity. Many of these concepts can be generalized and applied to other signatures, rules, code or programmatic functions, such as Snort, YARA, or ELK, in which a large quantity of multi-version discrete units must be maintained.

1. Balance efficiency with enough specificity to minimize false positives

The ultimate goal of any Splunk query is to search and present data in order to answer some question(s). There are many right ways to search in Splunk, but there are often far fewer best ways (yes, multiple bests, see next sentence). Before formulating a search query, a couple considerations should be weighed and prioritized, such as accuracy, efficiency, clarity, integrity, and duration. It is easy to get spoiled by simply doing wildcard searches, but also just as easy to unnecessarily bog down a search with superfluous key value mappings. An over reliance of either can lead to problems.

Accuracy - are there multiple sources which can answer the question? If so, which is more reliable and authoritative? More importantly, how important is it to reduce or eliminate false positives from your results? There is a heavy inverse correlation between accuracy and efficiency.

Clarity - filtering down to the most relevant information needed to answer the question is only half of the battle –you still need to interpret it. It may be fine to view the results as raw data if there are only one or two results of non-complex data, but when there are rows of deeply structured data, taking the time to present it in the most appropriate manner will go a long way.

Duration - the length required for the query to complete. Is this a search that will be run often, and so delays are additive and add to total inefficiency; is there an urgent need to answer something ASAP; is a longer duration eating up resources on other running functions on the search head? Sometimes it is necessary to break a search into smaller sub-searches or to target smaller sets of data and then pivot from there.

Efficiency - closely tied to duration, an inefficient query will lead to unnecessary delays, excessive resource consumption, and could even affect the integrity of the data (pay close attention to implicit limitations of results on certain commands!). Paying attention to efficiency is especially important if there are per-user limitations on number of searches, memory usage, or other constraints.Too many explicitly defined wildcard placeholders could become very expensive, and the atomicity of a formulated query should always be considered.

Integrity - will you be manipulating any data as part of your search? If so, understand the risks to compromising the integrity of your results in doing so. The more pivots made on returned data, the more susceptible to loss of integrity the search becomes.

2. Make it readable

Write queries in a consistent and clear manner. Sometimes it is better to have a query take up many additional lines for 3. the sake of better readability. Breaking into newlines on pipes is the defacto standard for readability purposes, as 4. can be seen below.

event_simpleName IN (SyntheticProcessRollup2, ProcessRollup2) ImageFileName="*Windows\\\System32\\\\regsvr32.exe" CommandLine="*/i:http*" AND ParentCommandLine="*scrobj.dll*"
| rex field=CommandLine "/i:(?<sct_file_tmp>\S+)"
| eval sct_file=replace(sct_file_tmp, ":", "[:]")
| eval ParentProcess=ImageFileName
| eval ParentCLI=CommandLine
| eval ParentUser=UserName
| rename TargetProcessId_decimal AS ParentProcessId_decimal
| join ParentProcessId_decimal 
	[search event_simpleName IN (SyntheticProcessRollup, ProcessRollup2)
	| eval ChildProcess=ImageFileName
	| eval ChildCLI=CommandLine
	| eval ChildUser=UserName]
| table _time ParentUser ParentCLI ChildProcess ChildCLI sct_file
view raw2.Make-it-readable.py hosted with ❤ by GitHub

3. Make it extensible

Queries should be written in such a way that other people can modify it for their own adaptations or to update or expand a current one. Some ways to accomplish this would be using obvious variable names, readability, or even leaving in inexpensive functionality or variables which can be used for other purposes.

4. Make it modular

Modularity will lead to extensibility, maintainability, and resiliency. This will also increase efficiency as code reuse will be much simpler.

5. Make it feasible

If the query is written for the purpose of manual sifting and analysis, then 50k results is not very reasonable. However, if it is for stateful preservation, alerts, or lookups, then that is more acceptable. Incorporating pivots on the information with subsearches and filtering or even, if necessary, breaking it up in to multiple different queries will make managing the results a surmountable task.

6. Make it resilient

The data can change and so can the SPL itself (or even custom commands if used), so writing queries that are less effected by potential changes is important, especially if the effects of the changes are not obvious, which could lead to a loss of integrity in the results. (This is where testing is also important)

7. Make it consistent

Having a style guide may seem like overkill, but if your operation is highly dependent on maintaining a repository of queries, it can go a long way. Naming conventions, spacing, line breaks, use of quotations, ordering, and style are some of the things to standardize to help with consistency.

8. Make it identifiable

Something as simple as:

 | eval queryID=wxp-110 

This ID can then be printed out with the results if needed or purely used as a means to categorize and quickly identify. Naming conventions should be obvious or recognizable (wxp = Windows XP, query 110), or even mappable to the repository itself.

9. Make it noob friendly

This is obviously highly dependent on your usage and organizational structure, however, it never hurts to keep queries as simple as can be, since there is always the chance that someone else will need to maintain or interpret them. Bonus* less time needing to train people on their purpose!

10. RTFM!

I am a huge proponent of RTFM (F!=field, btw) for both myself and others. Splunk has put a lot of effort into meticulous documentation, which is clearly reflected in the detailed and thorough documentation. With regards to writing SPL queries, the search reference is your absolute best friend!

11. Know your data

The first two things that I tell anyone to do that is new to Splunk is to familiarize yourself with the syntax of SPL (#10) and just as importantly, to get to know how the data is structured. The simplest way to do this is to do a wildcard search (*) and start reviewing the raw results under the events tab. The data will usually be structure in XML or JSON. Initially, it will be less important to know which data was structured from indexing, field extractions, or other transforms, but may become important with more advanced searches.

12.Test it

Do not ever merge a query into production ops, bless off on it, trust it, or whatever it is you do to give it legitimacy without first testing and confirmation of positive results. Regardless of how simple the query is, you can never guarantee that some other confounding issue isn’t occurring. If it is a matter of missing the applicable data, well then, Try Harder! There are many great products out there to help with this at scale, such as Red Canary’s atomic red team or Mitre’s caldera.

13. Build it out piecemeal

It can get stressful spending a lot of time on a query, only for it to not return the correct or any results, regardless of tweaking. The best way to build complex queries is to build them in pieces, testing as you go along. This is especially convenient because you can point to available data for the sake of testing to ensure positive results, and then change it as it is built out.

# ensure you have data for the computer
host=ComputerA  

# ensure you have data being parsed from that computer to the CommandLine field
host=ComputerA CommandLine=*  

# search for all occurences of python in command line activity for the computer
host=ComputerA CommandLine="*python*"

...

#search for all systems where powershell spawned a python program in which 3 or more parameters are passed
host=* ParentProcess="powershell.exe" process="python.exe"
| rex field=CommandLine "(\s-{1,2})(?<flags>\S+)" max_match=0
| stats count values(flags) by host
| where count>3
| sort 0 host

14. Implement version control

The necessity of this is really dependent on the amount of queries and modifications, though it makes sense even for small quantities. This can be accomplished as simply as baking a version into the query itself, such as from #8 with revisions tacked on with periods (wxp-110.3) or even in its own field: | eval version=3 Even better than that would be to maintain them in a database or repository such as GitHub, which gives the added benefit of stateful change representations. It is also possible to save searches directly in Splunk, the version control is less intuitive in this way.

15. Maintain multiple versions of the same thing

This doesn’t just apply to older versions of the same query, but queries which may search the same thing but present it in a different manner, search a different data set, or search a different time window.

16. Don’t reinvent the wheel

It is all too easy to blow a full 12 hour shift perfecting a query, which may not even end up working at all. While it is important to have these search queries catered to your specific need, it is not always necessary to MacGyver it alone. There are lots of great resources available to borrow ideas or techniques from, such as the Splunk blogs and forums, or you can even work with a co-worker.

17. Don’t depend on the wheel

Counter to #16, you do not want to become over reliant on searching for help, as this could lead to running queries which may not be working as you think they are. This could also potentially compromise the integrity of the results. Worse yet, it could be an inefficient way of doing something which has caught on and persisted through the forums.

18. Share it

If you have written a gem or come up with a novel approach to something, share it back with the community. Even if the data set is different, there may still be much which can be gleaned from it. It also helps to drive conversations which benefit the community as a whole.

19. Save it

This is such an obvious one, but in spite of that, I still constantly find myself rewriting queries that I had previously written over and over again…

20. REGEX!

I don’t know why I have this all the way down at #20, because this is easily one of the most powerful and important concepts for which to be able to pivot on results with. There are several commands where regex is able to be leveraged, but the two most significant are regex and rex.

Regex does exactly what it says –allows you to filter on respective fields (or _raw) using regex, which in Splunk is a slimmed down version of PCRE. The rex command is much more powerful, in that it allows you to create fields based on the parsed data, which can then be used to pivot your searches on. You can even build it as a multivalued field if more than one match occurs. An example of the rex command (and potentially more than one value) can be seen in the example from #13.

21. Know when its better to go beyond just using a search with SPL

Finally, we made it all the way to #21! Sometimes, depending on circumstance, function, and operational usage, manual searching with SPL queries is just not the best answer. Splunk has a lot of other functionality which can accomplish many of the same things, with less manual requirements. Alerts, scheduled reports, dashboards, and any of a number of apps built within or against the API allow for almost limitless capability. If you are struggling to maintain or achieve some of the topics annotated here, it may mean it is time to explore some of these alternative options.

Final Thoughts

This is certainly not an all inclusive list, as there are many more practices which can apply here. Ultimately, it depends on the specific deployment, implementation, and usage of Splunk which should dictate exactly how you create and maintain search queries. This was also not meant to go too deep in the weeds on generating advanced queries (though that may come in the future), but rather a high level approach to maintaining quality and standards. There are many other people who are far more experienced and with much greater Splunk-fu out there, so if you have any input or insight, please feel free to reach out.

originally posted on a previous blog of mine

There are many frameworks and methodologies that have been created around modern cyber threat hunting. Some of these particular implementations are specialized for specific environments, circumstances, or data sources, while others are more generic, applicable across any situation. The one thing which the majority of these methodologies have in common however, is the fact that they all leverage or reference an attacker lifecycle in some way.

There are many considerations and components which should be accounted for while preparing to execute a hunting mission, but a few of those include the following:

The Attacker Lifecycle The Cyber Kill Chain is an industry-wide de facto standard for modeling threats within the cyber ecosystem. The Kill Chain was originally created by several researchers at the Lockheed Martin Corporation as part of a methodology to more appropriately model and defend against increasingly advanced adversaries. The primary benefit of approaching defensive cyber operations from the perspective of the Kill Chain is a disciplined framework to focus and scope intelligence-driven defensive operations such as cyber threat hunting.

Defining Normality in Organizations It is just as important to assess and understand your own organization as it is profiling and understanding the enemy. This is one of the most common things that companies tend to struggle with. Inventory of assets, criticality of data, normal business to business (B2B) communications, etc. Fully understanding and awareness of these things makes defending (and proactively hunting) much more successful.

Intelligence-Driven This may be the most important factor within the entire threat hunting process. While the full details of how to execute this will be documented in a subsequent post, it is critical to understand that intelligence will not only scope the hunting process, but also provide relevance to any findings within the context of the attacker lifecycle.

Scoping Hunt Missions

The Cyber Kill Chain is broken down into the following categories:

• Reconnaissance
• Weaponization
• Delivery
• Exploitation
• Installation
• Command & Control (C2)
• Actions on Objectives

Many organizations with access to large amounts of data which they can hunt through will conduct both targeted and generic hunts. The kill chain is leveraged through both approaches.

With targeted hunting, the pre-defined scope of potential adversaries and their historically attributable tactics, techniques, and procedures (TTPs) are taken into account and broken out to the respective category which they fall under in the Cyber Kill Chain. This then allows analysts to focus on appropriate data sources necessary for locating Indicators of Compromise (IOC), Indicators of Activity (IOA), or anything else of relevance.

With regard to generic hunting, analysts can appropriately scope the focus of individual hunt missions based on the categories of the Cyber Kill Chain. Under this method, analyst can start hunting very broadly within the chosen category, making a series of pivots on the data returned, until it reaches a manageable size for the analyst to peruse through, line by line. Should any indicators or suspicious items be found, analysts can then shift the focus laterally across the Cyber Kill Chain to establish more evidence of an attack or escalate to a senior analyst to carry out the investigation.

The best way to understand the advantage of leveraging the kill chain for hunting is to see an example of it in action.

The Hunt

First, we must determine our data sources relevant to the hunt. In this case, system logs, security event data, and host level information are available. The advantage of having multiple sources of data, such as an MSSP with multiple customers, is an expanded, diverse data set for which to make comparisons. While this adds some complications in baselining, it significantly increases the value of the data set for comparative analysis to identify suspicious activity based on anomalies.

Under generic hunting, we can choose to look for specific identifiers within the respective category chosen, look for anomalies within the larger data set, or a combination of the two. Additionally, we must determine the window of time to focus on. For generic hunting, these missions are usually executed on cyclical rotations, ensuring activity from any given time gets coverage. Anomaly based generic hunting requires multiple successive pivots to systematically filter out more and more data, so for simplicity, we will focus on hunting for specific identifiers. Although this method also relies on successive pivots, it is much easier to demonstrate.

Two short example hunt missions are explored below.

Example # 1 – Actions on Objectives (Privilege Escalation) via net Command Usage

For this example we will explore a generic cyber threat hunt mission, focused on identifying activity categorized within the actions on objectives phase.

For this search we are limiting to a single customer, looking for all process creation events executing the net command within the last 24 hours:

The search has returned 121 results. While this is surely a manageable number of events for an analyst to investigate, we can clear them out even further by filtering out normal activity based on established baselines:

We can see that, across the customer’s entire environment, the 121 events are comprised of only 3 unique commands. Breaking this our further by individual system reveals even more insight:

Based on previously documented baselines and defining normality for this customer, we can determine that the wuauserv activity (Windows update automatic update service) is expected activity and rule it out. We can dig further into the net use commands:

The results (truncated for brevity) reveal the activity within the context of time. We can then compare this activity with the normal, expected activity within the respective systems (either by comparing to baselines or verifying with the customer).

If there were any suspicious results which could not be accounted for as legitimate, the next step would have been to paint additional context around it, such as by seeing what else the user is executing shortly before and after; what other processes are being run; and parent-child process relationships. Identified suspicious activity can then be compared to other data sources to enrich these findings and then to shift focus across the Cyber Kill Chain categories for extending context.

Example # 2 Exploitation Leveraging a Software Vulnerability (CVE-2017-5638)

For this next example, we will explore how finding anomalies in the data set can reveal malicious activity (or attempts). In this search, we are searching for event data to identify all unique request and response HTTP headers. We will not restrict to a single customer in this case in order to encompass a larger, diversified data set:

The (partial) list of results shows that it has captured over 50 unique HTTP headers. We can then look for certain outliers in the respective headers such as significantly higher or lower occurrences of a value or even significant differences in the length of the values themselves.

As we browse through the top values of each result, we discover an interesting finding within the request packet’s content-type header. Not only are there two entries far longer than the rest, but one also has a very high rate of occurrence.

We can further verify how much of an outlier this truly might be by examining all unique values. This reveals that there are some repeating patterns within the value itself. A review of the RFC will reveal that this is not expected activity. Of course we now know that this is the attempted exploitation of CVE-2017-5638, targeting Apache Struts, but this process shows how this activity might have been detected prior to its discovery and disclosure.

We can now make a pivot on this data to extract all of the attempted malicious command line activity by targeted customer within the Apache Struts vulnerability, so we can then search our host level data for verification that the commands were not successfully executed.

Conclusion

Cyber threat hunting is critical to effectively identifying potential threats or compromises by taking a proactive approach. There are many different methodologies and techniques to guide cyber hunt missions, but the right one should be dictated by specific circumstances. Regardless of how it is executed, examining the environment through the attacker lifecycle will help guide scope and provide additional insight which might not have been considered.

Taking a proactive approach to securing and detecting malicious activity within your environment is paramount in today’s technologically dependent landscape. Hunting through an attacker lifecycle or the Cyber Kill Chain will allow you to identify and stop threats which traditional signature-based methods might miss.

originally posted on a previous blog of mine

update: this was also released, in a shorter, modified version at this blog here as well as this white paper