Comment by commSync on "Detect ICMP-Ghost Implant ICMP and DNS Tunnelling C2 Traffic Using PacketSmith Yara-X & ICMP Detection Modules"

Hi, I'm the author of ICMP-Ghost.

Good analysis overall; you correctly identified the RDTSC high-bits constraint and the asymmetric ID+SEQ authentication. These are real structural fingerprints.

However, I'd push back on the conclusion that these rules defeat the evasion claims:

All rules target the default public build constants. Changing three values; the auth sum (45000/55000), the mimicry padding sequence, and the DNS fake domain breaks every rule you've written. That's a 5-minute recompile for any operator.

More importantly, the VTable protocol pivot (!D/!I) is completely invisible here. An operator who pivots to DNS mid-session and changes the default chunk size produces traffic none of these rules match.

The XOR key (0x42, +0x07) is also hardcoded and public — but your rules don't decrypt the payload to inspect plaintext commands. That would be the harder, more robust detection approach.

These rules detect the toy/demo build, not a hardened operational variant. The evasion claims hold against production deployments.

JM00NJ

Hi commSync,

Thank you for taking the time to read the article and for your input.

While I understand your pushback on the conclusion, the generalization and the ability to detect such tunnelling traffic using the PacketSmith Yara-X detection module without writing any script, and with relative ease, is a feat in itself.

Your concerns about changing those constants in the code to bypass the detection logic are valid for much malware C&C traffic, except that in your case those constants are embedded in the code itself and are not provided in a separate configuration file. I reckon that a lot of threat actors, read-teamers, script kiddies, and general users of the tool would compile the code as is.

For the ICMP rules, I could also generalize them so they do not account for asymmetric authentication logic, albeit at the expense of some false positives.

With respect to the possibility of detecting the traffic by XOR-decrypting it (key-independent) on the fly, it is not "possible" since the data is VESQER-compressed before encryption.

In the section “ICMP Detection Module”, we demonstrate how the PacketSmith ICMP detection module detects suspicious/malicious ICMP Echo traffic using behavioural and protocol-semantic analysis, independent of any hardcoded rule.

Once again, thank you for your contribution to this article.

Best regards,

Hi M.,

Thank you for the detailed response.

One correction regarding your Type 7 detection: "istream starts with a reply packet > malicious". Looking at the source directly, the agent's very first action is to send an Echo Request (not a Reply):

asm ; --- First Beacon hello packet --- mov r12, 0 ; Empty payload call [rbp + 0x3010] ; VTable → _icmp_send (Echo REQUEST)

_sniff: call [rbp + 0x3008] ; Now enters recv loop

The istream begins with a Request from the agent. Type 7 would not trigger on a legitimate ICMP-Ghost session; it either produces a false negative here, or your test PCAP was replayed in a way that altered the packet ordering.

Regarding VESQER: this is not a known third-party library. It is a custom DPCM+RLE hybrid compression algorithm I wrote from scratch in pure x86-64 Assembly, with zero external dependencies.

The compression format has no public specification or magic bytes. Even if an analyst XOR-decrypts the payload (the key is public — 0x42, +0x07 per byte), they get compressed data in an undocumented custom format with no standard tooling to decompress it. Two layers of obscurity, not one.

Finally, on scalability: PacketSmith operates on offline PCAPs. In enterprise environments processing tens of thousands of ICMP packets per second, per-stream behavioural correlation becomes computationally impractical for live traffic. The detection works well for forensic post-mortem analysis, but not as a real-time prevention mechanism, which is where the original evasion claim stands.

Best regards, JM00NJ

That said, I acknowledge that the rules are effective against the default public build, and realistically most users of this tool would compile it as-is without modifying the constants. For that threat model; script kiddies and unsophisticated actors, the detection logic is valid and useful. The original evasion claims hold specifically against a hardened, operationally configured deployment, not the out-of-the-box version.

No, it is not the agent sending the first ICMP Echo Reply packet; it is the system's ICMP network stack. This is what I said in the article:

"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."

You can see it in the attached pcap traffic screenshot for packets 5, 6 and 7. Try it on your own, and let me know the results.

I have no issue with your points on scalability.

Search Hashnode