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.

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