Welcome back, my novice hackers!
One of the most common questions that Null Byte readers ask is: "How can I evade detection by antivirus software on the target?" I have already talked about how AV software works, but to obtain a deeper understanding, what better way is there than opening up and dissecting some AV software?
For the remainder of this series, we will be dissecting the most widely used, open-source, multi-platform AV software in the world, ClamAV.
Just a quick side note before we begin: when I use the term antivirus, you can substitute anti-malware. I prefer the term anti-malware as viruses are a subset of malware, but the industry and the public still use the term antivirus, so I will use them synonymously. Please don't be confused.
About ClamAV
ClamAV is an open-source (GNU public license) project that was purchased by Sourcefire in 2007, the same company that purchased Snort. When Sourcefire was purchased by Cisco in 2013, both Snort and ClamAV became a part of Cisco, the networking giant.
As detailed on their blog:
"The ClamAV detection engine is multifaceted—heuristics, support for numerous archivers (ZIP, RAR, OLE, etc.), tons of unpacking support (UPX, PEtite, NSPack, etc.), and several different content inspection engines.
"MRG did a third-party evaluation of Immunet Protect (uses ClamAV as one of its engines) where it outscored 15 other leading AV vendors and was the ONLY product that had a 100% detection rate."
ClamAV is just as effective as commercial antivirus software, and is widely utilized to protect email gateway systems, though, generally not consumer level systems. ClamAV did recently develop a Windows version, so its acceptance at the consumer level is likely to improve.
The beauty of working with ClamAV is that it is open source, so we can open it up and look inside to see and understand how it works. By doing this, we will have a better understanding of how all AV software works, and therefore can better devise strategies to evade it. This is not to say that all AV software works the same, but they do work similarly.
In this series, we will be examining the structure and operation of ClamAV. We will also look at its malware signatures, as well as develop our own malware signatures based upon some of the malware we use here on Null Byte to learn about hacking.
Step 1: Fire Up Kali
The first step, as usual, is to fire up Kali and open a terminal.
Step 2: Download ClamAV
Next we have to download and install ClamAV on our Kali Linux system. There are multiple ways you can download ClamAV. The first, and probably the simplest, is to use the APTITUDE package manager:
kali > apt-get install clamav clamav-freshclam
Or, you can browse to the ClamAV website and download it. Just make certain you download the Debian Linux version as Kali is built on Debian.
Finally, you can clone it directly from the Git repository at:
kali > git clone http://git.clamav.net/clamav.devel.git
This is the method that I would advise you to use here for our purposes, as it installs the developer version of ClamAV.
Once ClamAV is downloaded, navigate to it's directory by typing:
kali > cd clam-devel
Then, let's look inside the directory to see what files and directories ClamAV installed.
kali > ls -l
Step 3: Configure & Make ClamAV
If you cloned the developer version of ClamAV, you will need to configure and make it. To configure ClamAV, use:
kali > ./configure
To make ClamAV, use these two commands:
kali > make
kali > make install
Be patient, these steps can take awhile. I also recommend that you run ldconfig before proceeding any further:
kali > ldconfig
Step 4: Download the Virus/Malware Signatures
Now that we have ClamAV installed and configured, let's get the virus signatures. ClamAV stores these signatures in compressed files named main.cvd and daily.cvd. The main.cvd is a database of known virus signatures, while the daily.cvd is the "daily" updates to the virus signatures (actually, ClamAV updates signatures 4x per day).
You download the main.cvd using wget by typing:
kali > wget http://database.clamav.net/main.cvd
And then the daily updates of malware signatures at:
kali > wget http://database.clamav.net/daily.cvd
Detection Databases in ClamAV
ClamAV maintains a number of databases of malware that it uses to compare the files it is examining. These include:
- MD5 hashes of known malicious binaries (.hdb)
- MD5 hashes of PE sections (.mdb)
- Hexadecimal signatures (.ndb)
- Archive metadata signatures (.zmd or .rmd)
- Whitelist of known good files (.fp)
Step 5: Examine ClamAV Signatures
The signatures in ClamAV are compressed binary files. If you want to view a virus signature, you must first uncompress the file. To do this, ClamAV comes with a special tool to view its signature files, named sigtool, which stands for "signature tool," presumably.
Navigate to the sigtool directory within ClamAV and type:
kali > ./sigtool
This displays the help file for sigtool. It is this tool that we will be using throughout this exploration of ClamAV. You can see some of the switches for this tool in the screenshot above.
Step 6: Unpack the Signatures
There are two signature files, main.cvd and daily.cvd. The first being the primary database of signatures, the latter being the daily updates of signatures. Let's unpack them now with sigtool and take a look. We will use the -u switch for unpack.
kali > sigtool -u main.cvd
kali > sigtool -u daily.cvd
After unpacking these signatures, we can see many more files in the ClamAV database directory. These are the uncompressed signatures.
Step 7: View the Signature Files
Next, let's take a look at some of the signature files. We can use the Linux command more to display the contents of the daily.ndb file. The daily.ndb file is the hexadecimal representation of the signatures. This means that the signature name will be in ASCII, but the signature itself will be in hex.
As you can see in the screenshot above, the name of the signature (circled in red) is in ASCII (WIN.Trojan.Lolu and Win.Trojan.Vobfus), but the rest of the signature is in hex. In the next tutorial, we will convert that signature to ASCII, then look at the signature language of ClamAV and decipher what the signature is looking for.
A Final Note
I do not recommend that you activate or run ClamAV on your Kali system, since nearly everything we use is known malware. ClamAV will identify your tools as malware and try to quarantine them, hence making your Kali a mess. If you have followed my instructions here, ClamAV is not activated and the daemon is not running—it should not interfere with your hacking platform.
Keep coming back, my novice hackers, as we explore the inner workings of AV software!
Just updated your iPhone to iOS 18? You'll find a ton of hot new features for some of your most-used Apple apps. Dive in and see for yourself:
24 Comments
+1, because OTW has always something interesting out of his hat :) !
On a side note, for anyone wondering about AV companies, state sponsored malware and related, I suggest this old but insightful article, just in case you are mumbling about the openness of antivirus systems.
Infer your conclusions and, as always, trust no one (Mulder knows best)
A simple question, if one built a script to rewrite and scramble the signatures , could we effectively disable the ClamAV? Is there a standard approach to killing AV software?
-Defalt
But we don't want just to disable the AV... doing so would open the door to EVERY kind of malware on our target, while we want only OUR payload undetected and keep the others at the door. While I'm not practical of ClamAV inner working, i'd look into the Whitelist of known good files (.fp) mentioned and see if I can insert my signature and go undetected, or I just have to delete it from another file.
Another example. Say we encode a payload using veil-evasion, and we want to slip it past the ClamAV, adding that signature to the whitelist would essentially be handing the signature over to the AV companies, rendering veil-evasion encoding useless.
-Defalt
Not sure about this one !!
IF you add a signature to whitelist, who told you it's gonna spread like AIDS to other av companies? (if you really want to know, look into the souce, that's the cool thing of being open source :) ) I dunno how WL are handled, but that wouldn't be practical to just broadcast blindly a custom signature to everyone as malicious. Also, a signature is soooo generic that we could make it look for hardcoded values in our payload and make a per-user exception, rendering even signature very unique, and its broadcast useless.
It's not the act of putting it in the whitelist that gives it away, it's when it gets found in the whitelist and reported to the AV companies. You might as well just upload it to VirusTotal.
Also, I'm fairly certain that modern AV is smarter than that as it will attempt to predict the behavior of the file in question combined with what it knows of files from the same family.
-Defalt
indeed there is behaviour analisys, sandboxing, etc, but I think (and this is all to verify) that the white list will make the file run without questioning (that's what I would demand from a whitelist, even if it's not top notch security concept). And nobody said that THE signature must be a unique payload hash identifier. It might be in another portion of the code, totally unrelated, totally arbitrary,
I agree on the whitelist giving the green-light to files that meet the specifications, I think one of the issues will be tricking it into the whitelist in the first place. It can't be as black and white as "If it's there, run it". There has to be more at play. (Good thing this is open source so we can tear through it!)
-Defalt
Exactly, the fact this is open source makes it easier to understand how signatures are made and how to build a signature that whitelists our payload without giving out too much information about the payload itself, and make it dependent on more random junk data we add to it.
Interesting, but what if my intent is to install more malware on the victim to keep track of their activity. Or just multiple different malware programs, I'd rather bring the whole thing down than hand over my signatures flat out.
-Defalt
True, you want more stuff in ! BUT you don't want others to take advantage of this situation and make a wild party in your target's computer... bringing it all down won't probably go unnoticed by the admin, plus might open the way to more aggressive malware that kill your access and grant their own exclusive.
For the small plan you might be right, but if you have to think at something bigger, just nuking the AV is not the best idea
My main concern of your method is giving away the signatures. You're practically handing them the means to lock you out. I'd rather chance another attacker and a pesky admin (That might not even exist!) than give them the information needed to lock me, you, and anyone else trying to use the same malware out.
-Defalt
Like I said in the post above, signature is arbitrary, I can make an undetected payload and add some random garbage data like ffee6655ddaabbcc115588 and add that byte sequence to whitelist. Whenever that sequence is hit, that file is safe, and your payload cannot be recognized or inferred by that.
It doesn't take a genius to match a few strings together, our enemy in this situation is not the AV, it's the people investigating it.
-Defalt
(un)fortunately, you can have a suspicion only AFTER the damage is done, and after you realized there was an actual intrusion (that's not so immediate). So the people investingating it will need time, samples, backtrace,.. meanwhile, you're gone with the loot, and next time you'll just show up with another signature.
Excellent point, but anyone who knows anything about InfoSec could catch the intrusion immediately with a quick netstat.
-Defalt
There are ways to make it stealthier, like the https payload, but genereally, yeah, you are right, a quick netstat could spot something wrong IF you know there is something to investingate, unusal port traffic, time patterns in connections, dns queries, but as an attacker you should learn how to overcome those, right because you KNOW what you're going to inspect (as a defender) when you suspect something's wrong.
I'm well aware of the presence of other AVs, but as of right now I'm solely interested in decimating ClamAV.
I've enjoyed this conversation as well, have a good night/day!
-Defalt
Oh, and btw, ClamAV is just ONE of the many antivirus out there. Nabbing one is easy, nabbing all is a whole different story. Still, this a nice playground because you have a chance to do some whitebox testing. Other AVs don't give us this opportunity.
Been nice to chat with a smart person, see ya soon Defalt.
True, I guess it all comes down to the victims knowledge of cyber security, apart from the AV bypassing method used. I'm interested to see where these theories lead, I might do some digging around in the ClamAV source tomorrow, see what I can find.
-Defalt
hey,
i tried to download ClamAV and it worked with the apt-get but not with the git clone, when im looking for it I dont see it even when im writing locate clam in the terminal.
you know why?
thanks!
You should try this one:
kali > git clone https://github.com/vrtadmin/clamav-devel.git
i get this error after trying to configure my ClamAv
checking check.h usability... no
checking check.h presence... no
checking for check.h... no
configure: unable to compile/link with check
checking for libxml2 installation... not found
configure: *** libxml2 support unavailable
checking for OpenSSL installation... /usr
configure: error: OpenSSL not found.
I downloaded clamav from git repository . But after configure and make ,in make install this error comes(screenshot):
btw i use elementary os (ubuntu deriative) which works fine for many tools such as metasploit(since i messed up with kali and backtrack on virtualbox) so can u mention the tools mainly which i need to use for your tutorials with their commands (except for metasploit nmap and john, i got them)
Share Your Thoughts