Netomize Official Blog

Hello, Regarding your point "Does Frame Bench recalculate IP, TCP and UDP checksums automatically after an edit, with an option to keep a deliberately broken one for testing?". Yes, it does, and for other protocols too. It recomputes lengths and checksums after every edit, padding included. You may turn this auto computation off so that it doesn't auto-fix them, and instead fix them on a packet-by-packet basis, from the decoded packet or a centralized Health check window. "A diff view between the original and edited frame would also make it easier to attach modified captures to bug reports with confidence." Currently, Frame Bench allows you to diff multiple different frames at the same time at the byte level and protocol semantics level, but not for the same frame (Byte diff of up to five frames. Export as HTML, Markdown or unified diff). We'll add the capability to “Compare with original” for the same frame, that's a good idea. Additionally, Frame Bench supports a separate “Capture diff” window, comparing the loaded capture against another file. Thank you, for your input. If you have any other questions, please let us know.

Fair enough!

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.

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