Hack Like a Pro: How Antivirus Software Works & How to Evade It, Pt. 3 (Creating a Malware Signature in ClamAV)

How Antivirus Software Works & How to Evade It, Pt. 3 (Creating a Malware Signature in ClamAV)

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.

Step 1: Fire Up Kali & Open ClamAV

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

Step 2: Create an ASCII-Based Signature

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
nullbyte

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:

6e756c6c62797465

Step 3: Signature Format

Next, we want to create a malware signature file. The basic signature format in .ndb files is:

SigName:Target:Offset:HexadecimalSignature

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
6= ELF
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:

NullByte:0:*:6e756c6c62797465

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.

Step 4: Test Whether Our Signature Works

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!

Step 5: A Touch More Complex Signature

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.

Step 6: Create a Signature Looking for Null & Byte

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:

NullByte:0:*:6e756c6c??62797465

Step 7: Using Offsets

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:

NullByte:0:69:6e756c6c??62797465

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:

NullByte:0:69,99:6e756c6c??62797465

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!

Just updated your iPhone? You'll find new emoji, enhanced security, podcast transcripts, Apple Cash virtual numbers, and other useful features. There are even new additions hidden within Safari. Find out what's new and changed on your iPhone with the iOS 17.4 update.

Cover image via Shutterstock

4 Comments

Would a genuine malware signature be the binary code of the entire malicious process, or just certain sections of it?

If you wrote malware signature for astring like nullbyte, wouldn't basic word processors be flagged for containing those strings in memory? Or is only certain sections of program memory?

Theoretically, couldn't you write a program to rearrange it's signature in memory so as to aboid detection?

Generally, the AV developers attempt to find something unique in the malware that identifies it and then build a signature from it. They seldom use the entire binary code as that would be very inefficient.

As this is only meant to demonstrate signature writing, the use of null byte string would not likely be a useful signature in the real world. Seldom to the AV developers have the luxury of writing a signature of an ASCII string.

Yes, there are many ways to rearrange the telltale signs of malware to avoid detection. That is what this whole series is about.

occupytheweb, you are awesome! Each of your tutorials is fun to read and I learn a lot from this! Thank you for all your hard work!

@occupytheweb

hallo , i don't understand the step 7 :

Let's assume that we know that the two signature words null and byte never occur before the 69th byte.

why 69 ?

so , null and byte have this bytes:
null = 110 byte
byte = 98 byte

Can you please explain me, what to do about to know this .

Thanks!

Share Your Thoughts

  • Hot
  • Latest