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