Travis Green

The Port Scoping Paradox: When Optimization Makes Things Slower

Thu, 12 Feb 2026 00:00:00 +0000

TL;DR: Port scoping in Suricata rules — a widely recommended optimization — can actually increase CPU usage by 20-30% when the traffic you’re analyzing is already on the target ports. Here’s the story of how I discovered this counterintuitive behavior and what it means for rule development.

The Setup: An “Obvious” Optimization

You’re writing Suricata detection rules for RDP brute force attacks. Your starting point looks like this:

alert tcp any any -> any any (
    msg:"RDP Brute Force Attempt";
    content:"|e0 00 00 00 00 00|Cookie|3a 20|";
    offset:5; depth:14;
    sid:7704787;
)

A colleague suggests what seems like an obvious win: “Why inspect every TCP connection? RDP runs on port 3389. Scope it to the port!”

alert tcp any any -> any [3388,3389] (
    msg:"RDP Brute Force Attempt";
    content:"|e0 00 00 00 00 00|Cookie|3a 20|";
    offset:5; depth:14;
    sid:7704787;
)

The logic is bulletproof, right? Most traffic isn’t RDP — maybe 1% of connections. Port scoping filters out 99% of packets before any expensive pattern matching happens. You save 99% of CPU on these rules.

Right?

The Twist

We ran the numbers. Single-threaded profiling mode, 5 iterations for statistical confidence, 376,460 packets of real network traffic. Both rule variants evaluated the exact same packets — “Checks” counts how many packets each rule fully evaluated.

Rule config	Checks	CPU ticks	Result
`any any`	1,010	382,581	Baseline
`[3388,3389]`	1,010	496,132	+29.7% overhead

🔍 Critical insight: Same checks (1,010), but port-scoped rules burned 113,551 extra CPU cycles doing the same work.

Look at the Checks column: both configurations evaluated exactly the same 1,010 packets. Port scoping did not prefilter anything. Because the test traffic was already RDP on port 3389, every packet matched the port condition — so the rule still ran on all 1,010 of them. The “optimization” never got to skip a single packet. It only added overhead to each one.

The result: 113,551 extra CPU cycles for the same amount of work.

I ran it again five times to be sure:

Iteration	Overhead
1	+26%
2	+37%
3	+32%
4	+26%
5	+29%

Coefficient of variation: 4.9% (anything under 10% is reliable). This wasn’t noise.

Why?

To understand what went wrong, you need to know what Suricata’s prefilter actually does.

Prefilter Uses fast_pattern, Not Ports

Suricata’s prefilter is built around fast_pattern — the content keyword that feeds the MPM (multi-pattern matching) engine. Only packets that hit a fast_pattern go on to full rule evaluation.

Port conditions aren’t part of prefilter. They’re checked during full rule evaluation, after MPM has already decided the packet is a candidate.

What Port Scoping Actually Adds

When you write any [3388,3389], you’re not adding an early exit. You’re adding an extra check that runs inside every rule evaluation:

With any any:

MPM scan → hit on content
Rule evaluation → content check → match

With [3388,3389]:

MPM scan → hit on content
Rule evaluation → port list traversal → content check → match

For packets on port 3389 that match the content (all 1,010 in our test), step 2 now does more work, not less.

The Port Matching Overhead

With any any, Suricata sees ANY_PORT and the compiler eliminates the check entirely. With a port list, a linked list must be traversed at runtime on every check:

Compiled away:

// any any: optimized away by compiler — zero cost
if (port_spec == ANY_PORT) {
    return true;
}

Runtime traversal:

// [3388,3389]: runtime traversal on every evaluation
for (DetectPortRange *range = port_spec->head; range != NULL; range = range->next) {
    if (packet_port >= range->low && packet_port <= range->high) {
        return true;
    }
}
return false;

The port list structure sits in L2/L3 cache, not the hot L1 cache where rule structures live. Every evaluation pays a cache miss to fetch it. Across 1,010 checks, the estimated ~120-240 cycles per lookup produces the 113,551 extra cycles we measured.

The overhead breaks down to:

Source	Share	Detail
Memory access penalty	~60%	Port list lives in L2/L3 cache; rule structures are hot in L1. Every lookup pays a ~100-200 cycle cache miss.
Function call overhead	~20%	The compiler can optimize `if (ANY)` to nothing. Port list traversal is runtime data — it can’t be eliminated.
Conditional branch overhead	~20%	Extra branch instructions, potential mispredictions, loop bookkeeping.

At the per-rule level for SID 7704787 the picture was even starker: 2,836 ticks per check without port scoping vs 8,420 with it — a +197% increase on a cold-cache run with only 2 checks. This is a worst-case result (no cache warmth), but it illustrates the mechanism clearly.

The Break-Even Point

The overhead is predictable enough to model. From the aggregate results above: 382,581 total ticks / 1,010 checks ≈ 379 ticks average baseline evaluation; (496,132 − 382,581) / 1,010 ≈ 112 ticks added overhead per check from port matching. The break-even is:

Break-even = T_base / (T_base + T_port)
           = 379 / (379 + 112)
           ≈ 77%

Port scoping saves CPU only when fewer than ~77% of your TCP traffic is on the target ports. Plotted out:

Network	RDP %	Effect	Use scoping?
General internet monitoring	0.01%	+99.9% faster	Yes
Enterprise network	5%	+77% faster	Yes
Security lab (mixed)	50%	+39% faster	Yes
RDP-focused investigation	85%	-11% slower	No
Pure RDP capture	100%	-27% slower	No

Practical Takeaways

Port scoping works well when:

You’re monitoring diverse production traffic (most common case)
The target protocol is rare (< ~80% of your TCP traffic)
You need to reduce false positives from rules triggering on wrong ports

Port scoping hurts when:

You’re replaying or analyzing targeted captures
Your traffic is already filtered (an RDP-only PCAP, a dedicated monitoring sensor)
Your rules are already lightweight and not consuming meaningful CPU

For RDP brute force rules specifically, I landed on keeping any any because:

We already have a solid fast_pattern for prefilter
The rules are already cheap (< 0.1% CPU in a 6,477-rule set)
RDP on non-standard ports is a real and common evasion technique
The profiling showed a 27% degradation with port scoping on this traffic

Measure, Don’t Assume

We assumed port scoping would save 90-95% CPU. The reality was -27%.

Before tuning rules:

Profile first: suricata -r test.pcap -S rules.rules --profile
Find hot rules: Check rule_perf.log — ignore rules using < 0.1% CPU
Know your traffic: What % is actually on your target port?
Test both ways: Measure with and without scoping
Deploy the faster one — not the one that “should” be faster

Port scoping isn’t wrong — it’s just situational. Documentation says it’s best practice, and for most environments it is. But “most” isn’t “all.”

The difference between good detection engineering and great detection engineering is measuring your assumptions.

Test environment: Suricata (containerized), single-threaded profiling mode, 376k packet PCAP of real network traffic, 5 iterations, CV 4.9%.

CVE-2025-8088: WinRAR NTFS ADS Path Traversal Vulnerability Analysis

Mon, 11 Aug 2025 00:00:00 +0000

CVE-2025-8088: WinRAR NTFS ADS Path Traversal Vulnerability Analysis

I was catching up on the weekend’s news when I saw a fantastic report from ESET pop up covering (yet another) rar file path traversal vulnerability. At first it seemed like there wasn’t going to be any details to dig into given the reports are careful not to describe the vulnerability in too much detail as to deter copy cat attackers. Also, interestingly, there is a fake poc on github which does not represent this CVE at all but I assume the author couldn’t resist the call of sweet sweet SEO (much like this author). However, I did find one of the file hashes in a sample submitted to any.run.

Fantastic! Let’s go!

First, it seemed like nothing had happened as there were no obvious malicious network traffic generated, but on deeper inspection of any.run’s report, I noticed a lnk file was launched in the “behavior activities” view.

This led me to look closer at the rar file iteslf and sure enough…

Here we can see the malicious bytes in action. According to rarlab.com STM section is NTFS alternate data stream so sure enough that matches the reported details from ESET.

From there, it was simple to create yara & suricata detection to find the /\x00\x00\x03STM.{2}\x3a[^\x00]*\x2e\x2e\x5c in network and file bytes.

suricata rules:

Thanks to James Emery-Callcott of Emerging Threats for adding a more durable path traversal PCRE: /\x2e\x2e\x5c/ => /^.{0,10}(?:\x2f|\x5c|%5[Cc]|%2[Ff])?(?:(?:\x2e|%2[Ee]){1,2}(?:\x2f|\x5c|%5[Cc]|%2[Ff]){1,}){2,}/

# note {,64} prevents runaway pcre, tune as desired
alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"CORELIGHT EXPLOIT RAR File ADS Path Traversal Inbound via HTTP (CVE-2025-8088)"; flow:established,to_client; http.response_body; content:"STM"; fast_pattern; pcre:"/^.{2}\x3a[^\x00]{0,64}(?:\x2f|\x5c|%5[Cc]|%2[Ff])?(?:(?:\x2e|%2[Ee]){1,2}(?:\x2f|\x5c|%5[Cc]|%2[Ff]){1,}){2,}/R"; reference:url,travisgreen.net/2025/08/11/CVE-2025-8088.html; classtype:bad-unknown; sid:7704721; rev:1;)

alert http2 $EXTERNAL_NET any -> $HOME_NET any (msg:"CORELIGHT EXPLOIT RAR File ADS Path Traversal Inbound via HTTP2 (CVE-2025-8088)"; flow:established,to_client; http.response_body; content:"STM"; fast_pattern; pcre:"/^.{2}\x3a[^\x00]{0,64}(?:\x2f|\x5c|%5[Cc]|%2[Ff])?(?:(?:\x2e|%2[Ee]){1,2}(?:\x2f|\x5c|%5[Cc]|%2[Ff]){1,}){2,}/R"; reference:url,travisgreen.net/2025/08/11/CVE-2025-8088.html; classtype:bad-unknown; sid:7704722; rev:1;)

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"CORELIGHT EXPLOIT RAR File ADS Path Traversal Inbound via raw tcp (CVE-2025-8088)"; app-layer-protocol:!http; app-layer-protocol:!http2; content:"|00 00 03|STM"; fast_pattern; pcre:"/^.{2}\x3a[^\x00]{0,64}(?:\x2f|\x5c|%5[Cc]|%2[Ff])?(?:(?:\x2e|%2[Ee]){1,2}(?:\x2f|\x5c|%5[Cc]|%2[Ff]){1,}){2,}/R"; threshold:type limit, seconds 600, count 1, track by_src; reference:url,travisgreen.net/2025/08/11/CVE-2025-8088.html; classtype:bad-unknown; sid:7704723; rev:1;)

yara rule:

rule CVE_2025_8088_rar_ADS_traversal {
   meta:
        description = "Detects CVE-2025-8088 WinRAR NTFS ADS path traversal exploitation"
        author = "Travis Green <travis.green@corelight.com>"
        reference = "https://www.welivesecurity.com/en/eset-research/update-winrar-tools-now-romcom-and-others-exploiting-zero-day-vulnerability/"
        date = "2025-08-11"
        version = "1.0"
        hash1 = "107f3d1fe28b67397d21a6acca5b6b35def1aeb62a67bc10109bd73d567f9806"
        tlp = "WHITE"
   strings:
        $x1 = "STM" fullword ascii
        $x2 = "..\\\\" fullword ascii
        $x3 = /STM..\x3a[^\x00]*\x2e\x2e\x5c/ ascii
   condition:
        uint16(0) == 0x6152 and 3 of ($x*)
}

There’s certainly much much more to be said about the file that is launched and TTPs around the campaign, but this will have to do for today. Also, shout out to Winrar developers, you have an amazing track record considering it’s been around more than 30 years..

Setting impacket & Metasploit to use SMB2

Tue, 29 Jul 2025 00:00:00 +0000

When testing detection capabilities in my Active Directory lab, I ran into a common issue: impacket tools default to SMB3, but I needed to generate SMB2 traffic for detection rule development. Here’s how to force both impacket and Metasploit to use SMB2 instead.

The Problem

Modern security tools like impacket automatically negotiate the highest SMB protocol version (usually SMB3), which makes it difficult to test detection rules specifically designed for SMB2 traffic patterns.

Solution 1: Impacket Configuration

For impacket tools, you need to modify the SMB dialect preference in the source code:

File: impacket/smbconnection.py (around line 79)

Change the preferredDialect parameter to force SMB2:

# Find this section in smbconnection.py
elif preferredDialect in [SMB2_DIALECT_002, SMB2_DIALECT_21, SMB2_DIALECT_30, SMB2_DIALECT_311]:
    self._SMBConnection = smb3.SMB3(self._remoteName, self._remoteHost, self._myName, hostType,
                                    self._sess_port, self._timeout, preferredDialect=SMB2_DIALECT_21)
    #                                                                 ^^^^^^^^^^^^^^^^
    #                                                                 Force SMB2 here

Available SMB2 constants:

SMB2_DIALECT_002 - SMB 2.0.2
SMB2_DIALECT_21 - SMB 2.1 (recommended)

Solution 2: Metasploit Configuration

For Metasploit modules, disable SMB encryption to force protocol downgrade:

msf6 exploit(windows/smb/psexec) > set SMB::AlwaysEncrypt false
SMB::AlwaysEncrypt => false

Verification

After making these changes, you can verify the SMB version using network capture tools like Wireshark or tcpdump to confirm SMB2 negotiation packets.

These modifications ensure your red team tools generate the specific SMB2 traffic needed for detection rule testing. Just remember to document these changes for your team - and hope attackers ~~don’t~~ do read your blog! 😉

Hunting for browser extension abuse

Tue, 15 Apr 2025 00:00:00 +0000

I came across a funny thing while digging into discord stealers. It seems the world of discord stealers is very much in the business of cryptocurrency theft, and as a result of many crypto wallets being browser extensions, we see these class of attacks frequently looking for these browser extensions to inject malicious javascript. I’ve introduced a new set to the TGI HUNT rules to detect these browser extension ID strings in HTTP.

For example, here is 1336 stealer v3:

To enumerate any new javascript inbound or identifying browser extension information outbound, I’ve introduce browser-extensions.rules available on the TGI HUNT git repo: https://github.com/travisbgreen/hunting-rules/

Arbitrary File Read in Jenkins via args4j (CVE-2024-23897)

Thu, 25 Jan 2024 12:00:00 +0000

Arbitrary File Read in Jenkins via args4j (CVE-2024-23897) - is this another `log4j`?

Please note that this analysis covers the vulnerability of @ expansion, not the entire attack chain possible from the advisory.

Background

The hot thing in the cyber security press this morning (25 JAN 2024) is a vulnerability in Jenkins allowing attackers to read arbitrary files. Jenkins has had a few vulnerabilities over the years, likely due to its incredible popularity and dominant marketshare in the CI/CD space inviting much code analysis and scrutiny.

The large market share along with the sensitive nature the data make it a hugely popular target among attackers. If successful, attackers can pivot into an organization’s cloud infrastructure using the highly privileged and long lasting accounts contained within.

When a vulnerability is released for Jenkins, we potentially have a very big issue on our hands, but is that the case for CVE-2024-23897? Let’s dig in.

The Announcement

Per Jenkins:

“This command parser has a feature that replaces an @ character followed by a file path in an argument with the file’s contents (expandAtFiles). This feature is enabled by default and Jenkins 2.441 and earlier, LTS 2.426.2 and earlier does not disable it.” Jenkins 2.442, LTS 2.426.3 disables the command parser feature that replaces an @ character followed by a file path in an argument with the file’s contents for CLI commands.

The Code

Examining the patch we can see that they have added ALLOW_AT_SYNTAX to allow/disallow what was called out in the announcement as the vulnerable code path, the @ file expansion. Also, we can follow the bread crumbs in that code to identify the vulnerable code in args4j here:

Here we have the logic from args4j where we test the first character for @-ness, and read all the lines of the file if true:

The Vulnerability

@ expansion seems like a convenient feature to launch java applications from the command line using a file full of arguments instead of each argument separately, and I’m not sure I’m comfortable calling it a vulnerability per se. This vulnerability is due to arbitrary user input arriving at a command line argument. It is important to highlight the difference between this and a wildcard expansion vulnerability, which IMO is much worse due to their arbitrary and unpredictable nature.

Impact

Do other software projects use this library in a vulnerable way? A github search reveals that is a pretty popular library, but a quick survey of search results shows most of the importers of this are command line utilities intended to interact with larger projects like these minecraft utilities, or are unlikely to the allow rich user interaction via web interface that Jenkins does (such as stratum-proxy)

Conclusion

For these reasons I don’t think we have another log4j type mega-bug in args4j, but rather a fairly straightforward input validation / surprise feature problem that is likely only to be exploited by authenticated users in Jenkins, and will have limited impact in other software utilizing the args4j.

No LLMs were harmed in the writing of this blog post.

TGI HUNT Ruleset Update

Tue, 23 Jan 2024 09:30:00 +0000

TGI HUNT - Update January 2024

Hey all, I’ve decided to start being more verbose about this project’s activity in the hope of generating more feedback from people checking it out.

Documentation

Documentation will slowly appear in the ruleset as reference links to this site. If there is a particular rule you’d like to know more about, simply open a github issue here and I will bump it to the top of the doumentation queue.

Ruleset Housekeeping

cleaned up spacing
removed some obsolete encoding rules
renamed & simplified 2610338
removed previously disabled JA3 rules

New Rules

xmrigCC Donation Mining Pool Domain

I found this domain while examining torminer. It is a hardcoded domain found in xmrigCC source code

Suspicious String Inbound (b64 DownloadString)

This was found analyzing malicious powershell downloading an exe file per CrackMapExec web delivery of implant

Powershell.exe Inbound to SQL (UTF-16LE)

This was found surveying MSSQL attack techniques in Metasploit and CrackMapExec

MSSQL Antivirus Error

This error was observed during adversary simulation against MSSQL, when the MSSQL antivirus found something naughty and refused the query/command

Malicious Shell Script Artifact Inbound

These artifacts were observed when a compromised system reached out for a script containing these lines, which are meant to disable command logging at the bash terminal. For example PEASS-ng, a local privesc utility, uses this technique.

MSSQL Configuration Changed Message

This is the output of sp_configure MSSQL stored procedure, which occurs when using any of the Metasploit techniques to execute on MSSQL.

MSSQL Blocked Stored Procedure Message

Observed in MSSQL when using Metasploit

Server blocked access to procedure ‘sys.xp_cmdshell’ of component ‘xp_cmdshell’ because this component is turned off as part of the security configuration for this server. A system administrator can enable the use of ‘xp_cmdshell’ by using sp_configure. For more information about enabling ‘xp_cmdshell’, search for ‘xp_cmdshell’ in SQL Server Books Online.

MSSQL Generic xp_cmdshell

This is a generic xp_cmdshell string observed across many red team github repos

Base64 Encoded EXE File in DNS

This came up in my daily reading, and I found an example from the venerable Didier Stevens. Note that I didn’t specify TXT record type here.

Easily Assemble Regular Expressions

Thu, 03 Feb 2022 11:02:00 +0000

List to regular expression

Have you ever encountered a list like this and thought “I wish I could easily create a regex to cover all these possible values”?

source

I have a linux based method to share which makes this task easy by leveraging an incredible Perl module called Regexp::Assemble

Step 1 - create a list

In our example, We’d like to capture all the possible values behind the ${ characters (we’ll deal with the leading characters later), so our first step is to list the values in a text document:

k8s
main
sys
lower
web
env
upper
date

Step 2 - assemble

Copy the following to a file (in this example it is named regex_assemble.pl:

#!/usr/bin/perl
use strict;
use Regexp::Assemble;
 
 my $ra = Regexp::Assemble->new;
 while (<>)
 {
   $ra->add($_);
   }
   print $ra->as_string() . "\n";

Note: you may need to install the Perl module

Then, we can copy our list to the clipboard and paste it into the STDIN of the invocation of our Perl script (note single quote):

$ echo 'k8s
> main
> sys
> lower
> web
> env
> upper
> date
> :
> ' | perl ~/scripts/regex_assemble.pl
(?:(?:low|upp)er|(?:k8|sy)s|date|main|env|web|:)

Notice the output: (?:(?:low|upp)er|(?:k8|sy)s|date|main|env|web|:)

Now we can add logic to account for preceeding characters

j[ndi]* will match the preceeding characters, note that this uses 0 or more of this character class logic and not a string match, a stylistic choice for readablity to cover partial strings: jn${.., jnd${, …

Also, it seems every string following ${ also follows with a : character, so we add:

j[ndi]*\${(?:(?:low|upp)er|(?:k8|sy)s|date|main|env|web|:):

Step 4 - use

In my case, I’m writing a hunting rule for use in investigating URL payloads, so a suricata rule using this regex would look like this:

alert http $HOME_NET any -> any any (msg:"TGI HUNT Possible Log4shell Obfuscation Technique"; flow:established; http.uri; content:"${"; fast_pattern; pcre:"/j[ndi]*\${(?:(?:low|upp)er|(?:k8|sy)s|date|main|env|web|:):/i"; reference:url,twitter.com/ymzkei5/status/1469765165348704256; classtype:bad-unknown; sid:2610828; rev:1;)

And a quick check shows that it is working:

$ ~/scripts/suri.hunting.sh
3/2/2022 -- 11:58:01 - <Notice> - This is Suricata version 6.0.2 RELEASE running in USER mode
<...>
3/2/2022 -- 11:58:01 - <Info> - Alerts: 1
3/2/2022 -- 11:58:01 - <Info> - cleaning up signature grouping structure... complete
02/02/2022-15:10:56.628683  [**] [1:2610828:1] TGI HUNT Possible Log4shell Obfuscation Technique [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 10.96.175.18:39376 -> 1.1.1.1:80

Hope that helps, and feel free to @ me with feedback.

Behavorial xbits with Suricata

Thu, 22 Jul 2021 09:30:00 +0000

The Setting:

While attempting to build detection for DeepRats as revealed by @benkow_, I managed to have (what I think) is a pretty good idea about using xbits. I’ll admit its a bit basic but I think sometimes the best ideas are deceivingly simple.

The Idea:

1.) observe potentially malicious behavior, set an xbit
2.) observe another potentially malicious behavior, set another xbit
3.) build detection consisting of a good fast_pattern match and xbits checks

Example (edited for clarity, full working example here):

IP check xbits set here:
alert tls $HOME_NET any -> $EXTERNAL_NET any (msg:"ET POLICY IP Check Domain (myexternalip .com in TLS SNI)"; flow:established,to_server; tls.sni; content:"myexternalip.com"; endswith; nocase; xbits:set,ET.ipcheck,track ip_src; classtype:policy-violation; sid:7704131; rev:1;)

alert tls $HOME_NET any -> $EXTERNAL_NET any (msg:"ET POLICY IP Check Domain (freegeoip .live in TLS SNI)"; flow:established,to_server; tls.sni; content:"freegeoip.live"; endswith; nocase; xbits:set,ET.ipcheck,track ip_src; xbits:set,ET.ipcheck,track ip_src; classtype:policy-violation; sid:7704132; rev:1;)

Known abused storage as dropper site xbit set here:
alert tls $HOME_NET any -> $EXTERNAL_NET any (msg:"ET POLICY IPFS Domain (storage.snark .art in TLS SNI)"; flow:established,to_server; tls.sni; content:"myexternalip.com"; endswith; nocase; xbits:set,ET.dropsite,track ip_src; classtype:policy-violation; sid:7704133; rev:1;)

Tor & final detection:
alert tcp any ![21,25,110,143,443,465,587,636,989:995,5061,5222,8443] -> any any (msg:"ET MALWARE Possible DarkRats Tor Traffic"; flow:established,from_server; content:"|06 03 55 04 03|"; pcre:"/^.{2}www\.[0-9a-z]{8,20}\.com[01]/Rs"; content:"|06 03 55 04 03|"; distance:0; pcre:"/^.{2}www\.[0-9a-z]{8,20}\.net/Rs"; xbits:isset,ET.ipcheck,track ip_dst; xbits:isset,ET.dropsite,track ip_dst; classtype:trojan-activity; sid:7704134; rev:1;)
Note: track ip_dst here because this detects the Tor RESPONSE traffic.

The final sig could probably also be a great HUNTING sig. Other HUNTING sig ideas:

Tor -> coinmining
IP Check -> HTTP POST
IP Check -> HTTP to frequently abused TLD

tweet me your ideas!

2032936 - Suspected Sliver DNS CnC FP Report

Tue, 18 May 2021 13:32:00 +0000

Background

It appears that SMTP MTAs and SMTP spam gateways utilizing DKIM sometimes make many _domainkey DNS TXT requests, which occasionally generate a false positive alert (FP) for rule 2032936. The cause of these alerts is a bit of inexact rule logic, which sometimes matches legitimate requests greater than a certain length that start with the underscore character: content:"_"; depth:1; content:"_domainkey"; distance:8;

For example, this non-malicious request generates a FP:
_conversica._domainkey.servicios.redactado.com

This example request would also generate a FP since distance:8; is not restricted to any bytes by the “within” keyword:
_asdfasdfasdfasdfasdfasdfasdfasdfasdf._domainkey.example.com

Here is an example of the malicious sliver CnC traffic which is the target of the original detection logic:

Analysis

We can refer to the sliver source code (convenient!) on github and search for the string “_domainkey” to find out the purpose and details of this traffic. Doing this reveals some lovely documentation on line 254 which explains the first part of the domain name is a nonce. The purpose of this nonce is to generate a unique name for the DNS request so if a DNS server has been configured to ignore a record’s TTL and always cache the name, we still have reason to perform recursion because it has never seen that unique domain name before.

The format of the nonce is an underscore character followed by a string of the length defined in nonceStdSize at line 66, containing random characters from the variable named dnsCharSet at line 77.

Modification

With this information we can update the rule logic to be more specific to this pattern and eliminate most FP.

content:"_"; depth:1; content:"_domainkey"; distance:8;
becomes
content:"_"; depth:1; pcre:"/^[a-z0-9_]{6}[^a-z0-9_]/R"; content:"_domainkey"; distance:8;

We’ve added a PCRE with a relative (“/R”) modifier to ensure the next 6 characters after the underscore are from variable dnsCharSet. With these changes we should dramatically reduce the number of false positives (but not entirely eliminate them, for example in the case of: _123456._domain.example.com)

original rule:

alert dns any any -> any any (msg:"ET TROJAN Suspected Sliver DNS CnC (original)"; content:"|00 10 00 01|"; isdataat:!1,relative; content:"|00 10 00 01|"; isdataat:!1,relative; dns_query; content:"_"; depth:1; content:"_domainkey"; distance:8; fast_pattern; reference:url,github.com/BishopFox/sliver; classtype:trojan-activity; sid:2032936; rev:1;)

becomes:

alert dns any any -> any any (msg:"ET TROJAN Suspected Sliver DNS CnC (modified)"; content:"|00 10 00 01|"; isdataat:!1,relative; content:"|00 10 00 01|"; isdataat:!1,relative; dns_query; content:"_"; depth:1; pcre:"/^[a-z0-9_]{6}[^a-z0-9_]/R"; content:"_domainkey"; distance:8; fast_pattern; reference:url,github.com/BishopFox/sliver; classtype:trojan-activity; sid:9999999; rev:2;)

Verify

Next we verify that our fix is good (if we have the luxury of pcap). Truth be told, I had a few small mistakes to fix and that is quite common for me.

Conclusion

The last thing to do is to submit to the mailing list and enjoy that sweet sweet open source community karma. Could we make this detection logic more precise? Probably, but we might risk creating a false negative by using too exact logic or including incorrect assumptions in our logic. Therefore we seek balance. Shout out to the BishopFox team for creating such a masterfully executed tool.

Please DM me with any rule analysis or FP/TP analysis requests.

Cobalt Group Report

Fri, 13 Sep 2019 12:09:00 +0000

Cobalt Group Report

Update/correction It has been brought to my attention that the attribution of this activity to cobalt group is not ironclad, it may change in the future.

Recently an excellent report by Checkpoint was published explaining recent developments of the Cobalt Group threat actor group. The Checkpoint report covers a lot of interesting TTPs and the evolution of techniques and procedures, but for now we will focus on detecting the unique C2 used by the group.

Cobalt Group recap:

financially motivated
targets eastern EU and central Asian banks
leader arrested in 2018
RU language decoy doc downloads & executes cobalt strike beacon via squibbly2
known to pivot from victim’s email account to infect others to exploit trust

C2 - The Interesting Bits

First we see the O365 Malleable C2 Profile as mentioned in the report, and as usual Cobalt Strike does an impressive job of masquerading its C2 as legitimate traffic.

HTTP Request:

First we have a long URL with legitimate looking /owa/ path and convincing parameters, but with no Referer this would have to be the first request, which seems odd. Also we have a Cookie header, again with no Referer; where did the cookie come from if this is the first request? There would be no chance for a server to respond with Set-Cookie, so this jumps out as odd.

Hunting sig idea: detect Cookie header with no Referer

We have a legitimate but ancient user agent string, and a dotted quad IP address. Cobalt strike is known for using a fake HTTP Host header, why do we not see that here? Looking at the source code mentioned in the article, we see that line 33 is commented out by default in this profile.

Further down in the file at line 93 we see what is really going on here. The real C2 data is contained within wla42= GET parameter.

All of the other static fields defined here would make for great detection strings, but would catch users of this exact profile only, and only in the default configuration.

HTTP Response:

We also see a lot of nice custom X- headers in the request convincing us of its legitimacy. One thing that jumps out as odd in the server response is that it is serving no data (Content-Length: 0). Could we build a hunting signature based on this?

Hunting sig idea 1: detect Content-Length: 0 and HTTP 200

From this information we can build these two signatures:

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"TGI TROJAN Cobalt Strike
 Malleable C2 Request (Cobalt Group O365 Profile)"; flow:established,to_server;
 http.uri; content:"/owa/?wa="; startswith; content:"&path=/calendar";
 endswith; http.header_names; content:!"Referer"; content:"Cookie";
 http.cookie; content:"MicrosoftApplicationsTelemetryDeviceId="; startswith;
 content:"|3b|ClientId="; distance:0; content:"|3b|MSPAuth="; distance:0;
 content:"|3b|xid="; distance:0; content:"|3b|wla42="; distance:0;
 reference:md5,a26722fc7e5882b5a273239cddfe755f;
 reference:url,attack.mitre.org/groups/G0080/;  classtype:trojan-activity;
 sid:1003918; rev:1;) 

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"TGI TROJAN Cobalt Strike
 Malleable C2 Response (Cobalt Group O365 Profile)";
 flow:established,to_client; http.header;
 content:"16723708fc9|0d 0a|X-CalculatedBETarget|3a 20|BY2PR06MB549.namprd06";
 content:"X-FEServer|3a 20|CY4PR02CA0010"; distance:0; 
 reference:md5,a26722fc7e5882b5a273239cddfe755f;
 reference:url,attack.mitre.org/groups/G0080/; classtype:trojan-activity;
 sid:1003919; rev:1;)

Additional Sample

Additional samples have come to light which show another malleable C2 profile being used, this time mimicing YouTube activity:

Here we see the fake HTTP Host common to Cobalt Strike Beacon. Also, interestingly we also have a null response from the server, but because the C2 profile pads the response, we do not see “Content-Length: 0” header in the response, instead we have “content=’’” for our empty response.

For these, we can detect with:

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"TGI TROJAN Cobalt Strike
 Malleable C2 Request (Cobalt Group YouTube Profile)";
 flow:established,to_server; http.uri; content:"/watch?v="; http.header_names;
 content:!"Referer"; content:"Cookie";
 reference:md5,69c6e302cc4394cae7ed8c6f7b288e92;
 reference:url,attack.mitre.org/groups/G0080/; classtype:trojan-activity;
 sid:1003920; rev:1;)

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"TGI TROJAN Cobalt Strike
 Malleable C2 Response (Cobalt Group YouTube Profile)";
 flow:established,to_client; http.header; content:"Frontend Proxy|0d
 0a|Set-Cookie|3a 20|YSC=LT4ZGGSgKoE|3b|"; fast_pattern; content:"X-FEServer|3a
 20|CY4PR02CA0010"; distance:0; reference:md5,69c6e302cc4394cae7ed8c6f7b288e92;
 reference:url,attack.mitre.org/groups/G0080/; classtype:trojan-activity;
 sid:1003921; rev:1;)

Signatures for Threat Hunting

If we implemented either of the proposed hunting sigs above, we would probably end up wading through huge amounts of alerts with potentially bad traffic somewhere in there, i.e. the proverbial needle in a haystack. Perhaps there is a way we can combine these two together to produce a less daunting haystack?

Consider the following:

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"TGI HUNT Possible Cobalt
 Strike Malleable C2 Null Response (Flowbit Set)"; flow:established,to_server;
 http.header_names; content:!"Referer"; content:"Cookie";
 flowbits:set,hunt.cs_null_response; flowbits:noalert; threshold:type limit,
 track by_src, seconds 60, count 1; classtype:trojan-activity; sid:2610202;
 rev:1;)

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"TGI HUNT Possible Cobalt
 Strike Malleable C2 Null Response"; flow:established,to_client;
 http.stat_code; content:"200"; bsize:3; pkt_data; 
 content:"Content-Length:|20|0|0d 0a|"; fast_pattern;
 flowbits:isset,hunt.cs_null_response; threshold:type limit, track by_src,
 seconds 60, count 1; classtype:trojan-activity; sid:2610203; rev:1;)

Here we are setting a flowbit on any HTTP request that has a Cookie set, but lacks the Referer header. Then we detect any HTTP 200 responses for 0 content length, then also check if the flowbit has been set by our previous sig. The end result is a strong indicator that further investigation is warranted. The caveat here is that these are signatures that will consume high amount of resources. In the first case, every request with a Cookie header will be inspected, and in the second case, any traffic with “Content-Length: 0” will be inspected. So these would not be great signatures for production use where network traffic is of any significant volume.

You can find these hunting sigs and more @ https://github.com/travisbgreen/hunting-rules

Comments? Suggestions? DMs open: @travisbgreen

Travis Green

The Port Scoping Paradox: When Optimization Makes Things Slower

The Setup: An “Obvious” Optimization

The Twist

Why?

Prefilter Uses fast_pattern, Not Ports

What Port Scoping Actually Adds

The Port Matching Overhead

The Break-Even Point

Practical Takeaways

Measure, Don’t Assume

CVE-2025-8088: WinRAR NTFS ADS Path Traversal Vulnerability Analysis

CVE-2025-8088: WinRAR NTFS ADS Path Traversal Vulnerability Analysis

suricata rules:

yara rule:

Setting impacket & Metasploit to use SMB2

The Problem

Solution 1: Impacket Configuration

Solution 2: Metasploit Configuration

Verification

Hunting for browser extension abuse

Arbitrary File Read in Jenkins via args4j (CVE-2024-23897)

Arbitrary File Read in Jenkins via args4j (CVE-2024-23897) - is this another log4j?

Background

The Announcement

The Code

The Vulnerability

Impact

Conclusion

TGI HUNT Ruleset Update

TGI HUNT - Update January 2024

Documentation

Ruleset Housekeeping

New Rules

xmrigCC Donation Mining Pool Domain

Suspicious String Inbound (b64 DownloadString)

Powershell.exe Inbound to SQL (UTF-16LE)

MSSQL Antivirus Error

Malicious Shell Script Artifact Inbound

MSSQL Configuration Changed Message

MSSQL Blocked Stored Procedure Message

MSSQL Generic xp_cmdshell

Base64 Encoded EXE File in DNS

Easily Assemble Regular Expressions

List to regular expression

Step 1 - create a list

Step 2 - assemble

Step 3 - refinement

Step 4 - use

Behavorial xbits with Suricata

The Setting:

The Idea:

2032936 - Suspected Sliver DNS CnC FP Report

Background

Analysis

Modification

Verify

Conclusion

Cobalt Group Report

Cobalt Group Report

C2 - The Interesting Bits

HTTP Request:

HTTP Response:

Additional Sample

Signatures for Threat Hunting

Arbitrary File Read in Jenkins via args4j (CVE-2024-23897) - is this another `log4j`?