Identifying antimalware signature

 Today's post will explain a simple method that allows you to identify a specific fragment of a binary file that your antimalware finds suspicious. This whole idea was born when I tried to download slammer.pcap file, with idea to see what this worm did with DCE RPC calls.

As soon as I tried to download the file from SampleCaptures - The Wireshark Wiki, my Endpoint Security agent triggered the alarm and deleted the file before it was written to the filesystem (and after it was downloaded). Note that this was no executable file format, the trigger was based on the inspection of a network capture (.pcap) file format.

The first thing I intended to do was to download the file somehow and actually inspect it in wireshark and with various tools for binary manipulation to see what exactly is triggering the alert. Once I downloaded the file (via tunneling from NAT-ed virtual machine), I loaded it in the Wireshark, and this is what it looks like.


At first glance, it was nothing much -approx 450 bytes all contained in a single packet destined to port 1434 (MS SQL server, just as expected), carrying some DCE RPC payload. My hypothesis here was that the antimalware triggers against payload contained within the DCERPC call.
After some trial-and-error attempts, I narrowed down the signature to the 16 bytes from the below sequence.

Note the sequence filled with "55555..." - this is the one that , once overwritten with "555..." allowed me free download.  Then I tried to determine what is so special about the original byte sequence that justified its selection as a malicious indicator. Initial search results pointed out to another piece of slammer worm that seemed to be used as a signature in a number of IDS/IPS and is outlined below. (The example post below suggested Snort signature targets the following bytes)


To be sure we're talking about the same file, I checked if this byte sequence exists in my sample and indeed it does.


Interesting - it does exist, but it seems my antimalware chose to select a different sequence. I than undertook to see what is so special about this sequence that triggered my inspection and to compare two of them. I found that the above sequence corresponds to the following code snippet from slammer.

Note that sequence targets pushing some fixed values to stack - this is a strategy that numerous antiviruses will use. They try to determine constants that assembler uses and which are hard coded into the source of malware. This strategy will fail with polymorphic malware that mutates by its every replica, but this was not the case with slammer. I continued my search to see whether other vendors or researchers had any other ideas - sure enough, they had.


Another signature I found in the above example seems to be actually prevalent in the research about slammer. So, again, I wanted to locate this specific byte array in my sample.


It was there. Another correlation search lead me to this part of code that corresponds to the signature above.

Again, a logical choice for antimalware- note the hard-coded constants , this time, though, not pushed to the stack, but xor-ed. Might be a piece of code responsible for simplistic encryption. (remember, xor?). Returning to the byte sequence that triggered my antimalware, I could identify this array:


And once again , the corresponding slammer code is this:

Once again, you will notice the pattern of bytes in the code that is suitable for an inspection. A constant value being moved to esi. After this very brief experiment, we can deduce one important aspect of antimalware software - if they are signature based (and many of them still are), they will try to find a piece of code that does not change and that contains hard-coded values to trigger.

Remember also that signature based recognition is not the only method to identify malware. Heuristic algorithms tend to replace signature based recognition more and more. Heuristic detection is based on behavioral analysis, so the dynamic aspect of malware mechanics. 

In this particular scenario heuristic could not help us much as this sample was a .pcap file (network capture file format that is not executable). Even though there are some papers describing .pcap files as being malicious that could execute via wireshark processing, in general, they are not.

Therefore, pcap does not execute in a classical meaning of the execution , the way how EXE/PE, or BAT, COM, ELF (Linux exeutable), python or powershells execute.








Comments

Popular posts from this blog

Signature verification bypass vulnerability in some Huawei routers

Attacking encrypted VOIP (SIP) protocols

Investigating suspicious emails