Welcome back, my budding hackers!
In this series, we are trying to understand how AV software works so that we can learn to evade it. To that end, we are working with the open-source AV software, ClamAV. I had previously introduced ClamAV in Part 2 of this series. If you have not installed it yet, go back to that and install it.
To understand how AV works, we will be building our own malware signatures in this tutorial. The more we know how these signatures work, the better we can develop methods to evade them.
In my previous tutorial, we had installed ClamAV in our Kali system. Also, remember that I had showed you how to use sigtool to unpack the malware signatures.
Let's navigate to the ClamAV directory:
kali > cd clamav-0.98.7
Let's assume that a newly discovered bit of malware has a unique signature that we can identify. We have isolated and disassembled it. Furthermore, let's assume that the signature is in ASCII. Next, let's assume that the ASCII signature is nullbyte. If we want to create a signature then for that malware, the first thing we would need to do is to convert that ASCII signature to hex.
Sigtool is a tool unique to ClamAV that enables us to work with malware signatures (hence the name signature tool). Let's use that tool to create hexadecimal signature of nullbyte. The syntax is simple and straightforward. Simply type the command sigtool followed by the --hex-dump switch. Hit enter, then input the ASCII you want converted to hex.
kali > sigtool --hex-dump
Note that after entering nullbyte as my signature, I hit enter and then sigtool generated the hexadecimal representation of it. Unfortunately, it took as input both nullbyte and the control character 0a, which is for when I hit the enter key signifying the end of one line and the start of another. (In Windows, this would be 0d0a, a combination of the CR (carriage return) and LF (line feed) characters.)
If we are to use this signature effectively in ClamAV, we need to truncate that 0a off the end, so that our signature becomes:
Next, we want to create a malware signature file. The basic signature format in .ndb files is:
Let's break that down to better understand:
- SigName is a unique ASCII name or label of the signature file.
- Target is the type of file. (See the table below.)
- Offset is the number of bytes from the start of the file to look for the signature.
- HexadecimalSignature is the hex representation of the signature of the malware.
The Target parameter is one of the following:
0 = any file type
1= Windows PE
2 = OLE
3 = normalized HTML
4 = email
5 = image files
7 = normalized ASCII
8 = unused
9 = Mach-O binaries
If we want to now use the hex signature we created in the Step #2 to look for that ASCII string in any file, we could create signature file like:
Let's break this one down now:
- NullByte is the unique name of the signature.
- 0 indicates look for the string in ANY file type.
- * indicates any offset (this is a wildcard meaning any).
- 6e756c6c62797465 is the hex representation of the signature.
We must then enter that signature into the main.ndb file in ClamAV for it to be used by the AV application. Open main.ndb in any text editor and place the signature into the file and save.
ClamAV has a utility called clamscan that enables us to test a signature file, but before we do that, we must create our malware file. Let's use any text editor to create a malware file with the signature nullbyte. I have created one below using Leafpad. Note that it includes the signature nullbyte.
I saved this file in /root/clamav-0.98.7/database, but you can save it anywhere, just remember the full path to it.
Now, we can test whether our malware signature file will be detected by ClamAV by using clamscan. Clamscan simply takes the -d switch, for detect, and the signature file followed by the malware file.
kali > clamscan -d /root/clamscan-0.98.7/database/main.ndb /root/clamscan-0.98.7/database/nullbyte-malware
As we see above, ClamAV detected our malware!
In Step #3, we used a simple signature of ASCII looking for the word nullbyte. What if the malware included both null and byte, but not necessarily together?
First, we would need to break up our hex representation into two separate pieces, one representing null and one representing byte. Since the hex representation is simply a character for character "translation" with each ASCII character represented by two hex characters, we can assume that the first eight hex characters represent null and the second eight characters represent byte. Let's check to make sure and enter null into our sigtool and see what it spits out.
As you can see, when the sigtool converted the ASCII null to hex, it spit out the first eight characters of our original hex signature with the 0a tacked on the end to represent the enter key. So, now we know we can create a new signature using both words and look for them in different places in the file.
Now, let's create a signature looking for the words null and byte, but not necessarily together. ClamAV has a number of wild cards we can use. In this case, let's use the wild card ??. This wildcard represents any number of bytes between 0 and 255 (0-FF). If we put it between null and byte, it will look for those two words together (0 bytes between) or up to 255 bytes between them (FF bytes between). We can now rewrite our signature as:
One of the arts of writing good signatures is to make them as efficient as possible. AV software that has to look at every byte of every file would be VERY sloooooow. To make our signature a bit more efficient, rather than having ClamAV look throughout the entire file (0 offset), we can specify where it should look in the file for the signature. This obviously would be far more efficient. Of course, it assumes that we know where the signature is in the file, and usually, we will.
Let's assume that we know that the two signature words null and byte never occur before the 69th byte. Where previous we had used the wildcard * in the offset field, we can be more specific and ONLY look in the 69th byte. We can rewrite our signature as:
Notice that we replaced the wildcard in the Offset field with 69.
Furthermore, we might know that the signature words never occur after the 99th byte. We can then put in a range of offset values so that ClamAV only looks in the 69th through the 99th bytes by rewriting our signature as:
Note that in the offset section of the signature, we have the value of the first byte, 69, followed by the last byte, 99, with a comma separating them.
Now that we have learned to write a simple malware signature in ClamAV, we will work toward writing more advanced signatures in this series. Keep coming back, my budding hackers!
Want to start making money as a white hat hacker? Jump-start your white-hat hacking career with our 2020 Premium Ethical Hacking Certification Training Bundle from the new Null Byte Shop and get over 60 hours of training from ethical hacking professionals.