{ "id": "d855f847-1680-4172-be4e-bf6fe12db93e", "created_at": "2026-04-06T00:11:58.236902Z", "updated_at": "2026-04-10T13:11:43.026331Z", "deleted_at": null, "sha1_hash": "975526ae7f9ddee354d12d7e21b604a07a606acc", "title": "Detect SnappyClient C\u0026C Traffic Using PacketSmith + Yara-X Detection Module", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 233352, "plain_text": "Detect SnappyClient C\u0026C Traffic Using PacketSmith + Yara-X\r\nDetection Module\r\nBy Netomize Official Blog\r\nPublished: 2026-03-23 · Archived: 2026-04-05 17:04:41 UTC\r\nIntroduction\r\nZscaler published a blog post about a new malware called SnappyClient, written in the C++ programming\r\nlanguage. The malware communicates with its C\u0026C server using a custom binary protocol. The traffic is\r\nencrypted with ChaCha20-Poly1305 using a key and nonce received from the server, which are exchanged and\r\nvalidated before any control commands are sent or received. I've selected this sample because the C\u0026C traffic\r\nstructure is almost unfilterable, even with a traditional IDS/IPS, without incurring a high rate of false positives or\r\nsignificant performance impact.\r\nThe variant with the following information (in the table shown below) matches the C\u0026C traffic dissected by\r\nZscaler threat research blog. The sample is available on VT.\r\nAttribute Value\r\nMD5 ec8258adfbf4ba5b9e8a06d75c5634cc\r\nSHA-1 feb928a54be40ad4bbf245aaae6968f83b4937f5\r\nSHA-256 eb523f6b0f306ce9fb68adeadac41d2c25b720075f03c75bd3611584dee28cf9\r\nFile size 3053296 bytes\r\nFile Type Win32 EXE\r\nVT's sandbox has a full capture of the C\u0026C traffic, and I've made it available for download via Netomize's official\r\nrepo (RFiles), SnappyClient Traffic VT (48.9 KB).\r\nThis blog post is about writing detection logic for the C\u0026C traffic based on PacketSmith + Yara-X detection\r\nmodule, using custom pattern identifiers. For an in-depth analysis of how the malware works, please refer to the\r\nZscaler blog post.\r\nOnce the malware successfully connects to the server, it receives a ChaCha20 key, a nonce, and a control session\r\nID. Subsequently, SnappyClient sends an encrypted packet with the message header, followed by another packet\r\ncontaining the encrypted and compressed message. Our focus is on the structure of the second packet sent by the\r\nmalware to the server, used for reporting back to the C\u0026C server. This packet is transmitted via the TCP protocol\r\nover ports 3333/3334 to the C\u0026C server at 151[.]242[.]122[.]227.\r\nhttps://blog.netomize.ca/detect-snappyclient-c-c-traffic-using-packetsmith-yara-x-detection-module\r\nPage 1 of 5\n\nFigure 1 - SnappyClient Egress Cmd Packet\r\nThe structure of the packet in Figure 1 is as follows:\r\nOffset Length Description\r\n0x00 0x02 Packet length in little-endian, starting from offset 0x03\r\n0x02 0x01\r\nA flag indicating whether the packet contains output tag data or not (the data in the\r\ngreen box). 0x00 or 0x01\r\n0x03 uint16(0x00)\r\nEncrypted message (including output tag, depending on whether the flag at offset\r\n0x02 is set or not)\r\nDetection Logic\r\nWith the packet structure documented, we can develop detection logic to avoid false positives. The packet lacks\r\nunique content for anchoring, except for the byte at offset 0x02, which can be 0x00 or 0x01. This is insufficient\r\nfor quick pattern matching in real-time traffic. Additionally, the encrypted message begins at offset 0x03 and\r\ncontinues to the packet's end, minus the 16-byte output tag size if the flag at offset 0x02 is set.\r\nUnderstanding these limitations and indicators, we can develop a Yara-X + PacketSmith detection rule utilizing\r\ncustom PaIDs (Pattern Identifiers) such as tcp , ip , and flow , along with the advanced math tools and\r\noperations built into Yara-X.\r\nhttps://blog.netomize.ca/detect-snappyclient-c-c-traffic-using-packetsmith-yara-x-detection-module\r\nPage 2 of 5\n\nWe could derive a rule similar to the following:\r\nimport \"math\"\r\nrule snappyclient_malware_encrypted_pkt\r\n{\r\n meta:\r\n description = \"TCP encrypted and compressed packet (client-\u003eserver)\"\r\n reference = \"https://www.zscaler.com/blogs/security-research/technical-analysis-snappyclient\"\r\n filter = \"Frames (frames:)\"\r\n sha1 = \"feb928a54be40ad4bbf245aaae6968f83b4937f5\"\r\n author = \"Netomize\"\r\n date = \"22/03/2026\"\r\ncondition:\r\n tcp.is_set and ip4.is_set and not ip4.in_ip6\r\n and\r\n tcp.data.size \u003e 3\r\n and\r\n ip.dst.type == 1 // public\r\n and\r\n flow.to_server // direction\r\n and\r\n math.in_range(port.src, 1024, 65535) // ephemeral ports\r\n and\r\n with buf_size = uint16(tcp.data.offset), buf_offset = tcp.data.offset:\r\n (\r\n buf_size == (tcp.data.size - 3)\r\n and\r\n( uint8(buf_offset + 2) == 0x00 or uint8(buf_offset + 2) == 0x01 )\r\nand\r\nmath.entropy(buf_offset + 2, buf_size) \u003e= 4\r\nand\r\nmath.count(0x00, buf_offset + 2, buf_size) \u003c 8\r\n )\r\n}\r\nThe rule checks for the following atomic indicators\r\nFirst, we check that we're dealing with a TCP packet over IPv4 using the tcp.is_set and ip4.is_set\r\nPaIDs, respectively, while ensuring that this is not an encapsulated IPv4 in IPv6 packet ( not ip4.in_ip6 )\r\nThe minimum size of the TCP payload is 3 bytes ( tcp.data.size \u003e 3 )\r\nhttps://blog.netomize.ca/detect-snappyclient-c-c-traffic-using-packetsmith-yara-x-detection-module\r\nPage 3 of 5\n\nPacketSmith ip PaID can infer the type of the IP address using enum values (PUBLIC = 1,\r\nUNSPECIFIED = 2, PRIVATE = 3, CGNAT = 4, LOOPBACK = 5, LINK_LOCAL = 6,\r\nIETF_ASSIGNMENTS = 7, DOCUMENTATION = 8 and RELAY = 9, among others)\r\nThe destination IP address is public ( ip.dst.type == 1 )\r\nThe directionality of the packet is to the server ( flow.to_server )\r\nUsing the \"math\" module in_range function, we check the range of the ephemeral source port such that it\r\nis between 1024 and 65535 ( math.in_range(port.src, 1024, 65535) )\r\nWe use the with statement to alias the TCP packet payload offset and size\r\nwith buf_size = uint16(tcp.data.offset), buf_offset = tcp.data.offset:\r\nThe uint16 value at offset 0x00 in the TCP payload is equal to the payload's size, minus the first 3 bytes\r\n(the header)\r\nbuf_size == (tcp.data.size - 3)\r\nThe byte at offset 0x02 could be either 0x00 or 0x01\r\n( uint8(buf_offset + 2) == 0x00 or uint8(buf_offset + 2) == 0x01 )\r\nSince the data is encrypted and compressed, the entropy of the data has to be \u003e= 4\r\nmath.entropy(buf_offset + 2, buf_size) \u003e= 4\r\nYou can safely increase the value if you want to check for large encrypted messages\r\nFinally, using the \"math\" module and the function count() , we check the encrypted data in the packet for\r\nall occurrences of the byte 0x00 such that it is \u003c 8\r\nmath.count(0x00, buf_offset + 2, buf_size) \u003c 8\r\nRunning the above Yara-X rule through the linked pcap via PacketSmith and saving the result as XML, we get the\r\nfile yara_dte_2026_03_23_17_11_08.xml (use MS Excel to view it) with all the detections:\r\nPacketSmith.exe -i \u003cinfile_pcap\u003e -D yara:xml -F frames: -O .\r\nTo check for potential false positives, we applied the detection rule to two large pcaps from our collection (511MB\r\nand 136MB) and found zero hits.\r\nConclusion\r\nThe PacketSmith + Yara‑X approach demonstrates that even highly obfuscated, ChaCha20‑Poly1305‑encrypted\r\nC\u0026C channels like SnappyClient can be detected reliably without deep payload inspection. By focusing on\r\nprotocol-level fingerprints — the packet header, fixed-length framing, and the byte distribution—the detection\r\nmodule achieves a useful signal with potentially zero false positives and modest performance cost.\r\nhttps://blog.netomize.ca/detect-snappyclient-c-c-traffic-using-packetsmith-yara-x-detection-module\r\nPage 4 of 5\n\nAuthor: Mohamad Mokbel\r\nFirst release: March 23, 2026\r\nSource: https://blog.netomize.ca/detect-snappyclient-c-c-traffic-using-packetsmith-yara-x-detection-module\r\nhttps://blog.netomize.ca/detect-snappyclient-c-c-traffic-using-packetsmith-yara-x-detection-module\r\nPage 5 of 5", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "origins": [ "web" ], "references": [ "https://blog.netomize.ca/detect-snappyclient-c-c-traffic-using-packetsmith-yara-x-detection-module" ], "report_names": [ "detect-snappyclient-c-c-traffic-using-packetsmith-yara-x-detection-module" ], "threat_actors": [], "ts_created_at": 1775434318, "ts_updated_at": 1775826703, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/975526ae7f9ddee354d12d7e21b604a07a606acc.pdf", "text": "https://archive.orkl.eu/975526ae7f9ddee354d12d7e21b604a07a606acc.txt", "img": "https://archive.orkl.eu/975526ae7f9ddee354d12d7e21b604a07a606acc.jpg" } }