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