Pulling specific bytes out of a packet is the best way to get to the real truth of the content. Getting to this level of the content can help you in many use cases.
One of the hidden features of NetMon’s DPA language is that you can extract specific bytes out of a packet inside of a packet rule. Although NetMon classifies over 3,100 applications and extracts many thousands of metadata fields, there is always more to learn about network traffic. You may need to dive into specific byte level analysis if you need to:
For example, many malware infiltration and C2 channels use well-known protocols in unusual ways or generate custom protocols over base channels. (Gh0st uses a custom protocol on TCP<link.
Many of these communication channels are actually in clear text. Being able to passively extract the traffic gives you a unique defensive advantage and the capability to closely examine the details of the traffic. Whether you are exploring a specific targeted threat or trying to create more general alarms for TTPs, looking at the raw bytes is often the only way to go. For instance, you could end up discovering which commands were issued through a reverse shell (making it easier to identify, isolate and remediate a threat). You might also create new alarms based on unique signatures of threats that you don’t have other means of catching.
We haven’t publicly exposed this method call before because there’s risk associated with any packet rule impacting performance. With our Rule Your Network contest running, we’ve decided it’s time to share the proper techniques for extracting specific bytes out of a network packet using DPA.
This method call is pretty simple, and it allows you to pull out up to 4 bytes cast as a long integer:
It’s one line of code. How complicated can it be?
Although we’re really only talking about a single DPA method, this approach is complicated by several factors that require a specific use pattern:
The high-level logic for a packet rule extracting bytes should be:
In addition, if you are converting byte flags to text strings, make sure you properly declare your lookup table as a global variable.
The most efficient packet rule is one that never executes. Although it may feel strange in terms of logic, the recommended design pattern is to start the rule by applying “leave now” filters, such as:
However, GetLatestApplication forces a string comparison, which takes more compute cycles than a numeric comparison. With a quick check on a NetMon dashboard, you can find the application ID for ICMP. Open the Analyze dashboard and filter for application:ICMP. Then, open any session and look for the “ApplicationID” field (967 for ICMP). You can also find this information in the help by looking for “application codes.” With this tiny bit of legwork, you can make this line more efficient by changing it to:
Depending on your rule logic, some other possible exit filters could be:
The IEEE 802.1Q networking standard defines a method for enabling virtual local area networks over Ethernet. Although this is a wonderful standard and is used on nearly every network, it has one unfortunate side effect for our purposes.
Depending on the type of VLAN encapsulation, the packet we process may have 0, 4, or 8 extra bytes of “VLAN wrapper.” To get the correct offset to account for the VLAN, you have to check to see if the packet was wrapped in a single VLAN layer or “double tagged” with a service tag (ISP VLAN).
Fortunately, checking is as simple as pulling a different byte from the packet and comparing the value. Remember, you’re only looking to see if a VLAN wrapper is present. You don’t actually need to unpack the VLAN header or extract any data from it.
The logic for evaluating VLAN tagging involves looking at bytes 13 and 14:
The code looks like this (written as a function you can copy and paste and then call in a DPA rule):
Now we are finally ready to call our “one line” of code to extract the packet. We’ve already used the method in determining the VLAN offset:
Remember: You can extract up to 4 bytes at a time. If you try to extract more, you will generate a runtime error that will disable the rule.
The return value is an integer. Depending on what you need to do, you can evaluate the result as an integer, using hex notation, or using bit masks.
Once you get your answer, you can wrap up your rule by either voting to capture (or not), or by adding custom metadata.
Just remember that a packet rule has to be high performance. The more packets you have, the more times the rule runs. Any rule, no matter how simple, will have an impact on your NetMon.
Do not develop these rules in your production environment and make sure you monitor them closely when you enable them to prevent runaway resource usage. To monitor the performance of the rule, enable the rule and then look at the following diagnostic charts:
Look for documentation on the GetPacketBytes method to be made public in a future release of NetMon. In the meantime, feel free to follow the guidance here.
Security strategies are evolving; driven by regulatory requirements, customer expectations around data privacy and AI-driven…
In our April 2024 quarterly release, LogRhythm Axon showcases new enhancements from its two week…
In our April 2024 quarterly release, LogRhythm SIEM introduces new enhancements to bring you faster…