Random Links

09 Apr 2010
Just adding a couple of random links I found interesting over the past few days

First of all - the nmap survey!  Used as input for updates to nmap and to the sectools.org list.  If you havent already get in there and vote!
http://nmap.org/survey/
 
More on malicious pdf analysis at the ISC Diary. This one analyses a pdf that is using some interesting new Javascript obfuscation methods. 
http://isc.sans.org/diary.html?storyid=8587 
 
And while we are on the subject of javascript obfiscation, heres another online tool that can be used to unpack Javascript.  If you wish you can directly upload a PDF, pcap, HTML, or JavaScript file for it to grab the Javascript from.  Might be a good alternative if you ever find a script that Wepawet wont decode... 
http://jsunpack.jeek.org/dec/go
 
This is an interesting bit of software, that monitors API calls of a Windows process.  Might be very useful for malware analysis.... 
http://jacquelin.potier.free.fr/winapioverride32/
 
Last but not least, and a subject dear to my own heart, a post on the Metasploit blog on the question of whether a penetration tester needs to know assembly.  Yet another example of untrustworthy public exploit code is provided.  If you use exploits, you need to know how they work people! 
http://blog.metasploit.com/2010/04/penetration-testing-learn-assembly.html
 
Im still working (slowly) on the malware analysis post I promised a little while back, and as soon as my new laptop gets delivered I will start looking at the next of my buffer overflow tutorials.   I am planning for the next entry in the series to be much more difficult than what has been covered already, so take this down time to make sure you understand everything in the first five entries!

    

    
      
      
      

      
    
  

  
  

    

      
        Bypassing Antivirus Detection: Netcat
      
    

    

  03 Apr 2010
  
    
  




    
      Introduction

The subject of bypassing AV detection is one that comes up quite frequently in discussions in pentesting circles, and I was most recently reminded of it once again when it came up on one of the mailing lists I subscribed to.  In this particular case, the executable in question that people wanted to sneak by those evil AV scanners was the Windows version of netcat (nc.exe).

Since this was something I had looked at before, I contributed some of my own favorite methods to the list, but I thought it might also be a good idea to do a post about it here as well, giving a more detailed summary of the process, including my own methods and those mentioned by some others.  

The methods I am listing are specifically focused on Windows executable files, with nc.exe being used as the example, and may not be appropriate for other types of malicious code, such as macro viruses, although the theory (involving signature avoidance) is largely the same.

In addition, while it is possible to evade AV detection by encrypting a file (adding it to a TrueCrypt container, or a password protected zip file) I have not listed this method below.  This is because this method results in a program that cannot be run in its current form - it will need to be removed from the encrypted container first before it is run.  This can be effective in bypassing AV detection on content inspection gateways (virus scanning email servers for example), but a local virus scanner will usually pick the file up once it is extracted to disk before being run.

And of course I also have to give the standard warning here that I do before any post that may be put to inappropriate use.... don't be evil.

Now lets get into the detail.


Methods of Bypassing AV Detection

The methods for bypassing AV detection can be loosely grouped together as follows:
  • Binary Editing
  • Encoding
  • Packing
  • Source Modifcation
  • Recompilation
  • Use of Alternative programs


Virus "File Signatures"

What these methods all have in common is that they all work to try and modify the file signature of the target executable file in order to avoid detection.  A quick explanation of what a signature is could be helpful here.  

The most common method for virus detection is the use of a signature, which is a unique pattern of bytes contained within a malicious file.  This signature is usually quite small (perhaps only a few dozen bytes), and if you can modify the file such that those bytes are not present in the file when the virus scanner scans it, then no virus will be detected.  This could be as simple as the virus scanner expecting to see the characters "Now you are pwned!" at byte offset 200 in the file, and if you change the file to instead say "Now you are Pwned!" (changing the case of the 'p' in pwned), the signature will not be complete and no virus will be detected.  Now it may not always be possible to just directly modify the file signature in such a simple manner and still have the target executable run as intended, but there are other ways in which this same goal can be achieved other than just replacing text characters (more on this later).

Another important fact to understand about Virus Scanners related to the file signature issue is that the "scanning" of the file is usually done based on how it appears on disk.  Consequently, detection can also be bypassed if the file appears one way when opened from disk, but modifies itself when loaded into memory.

Now, checking for this type  of file signature is not the only technique used by virus scanning products to detect malicious code, however it is the most common, and in the majority of cases it is sufficient to modify the file signature in order to bypass detection.  The methods of AV avoidance discussed in this post are primarily focused on the file signature method, but some might also be effective (with a little modification) against other detection methods.  If you are interested in some of the other methods of virus detection, "The Art of Computer Virus Research and Defense" by Peter Szor is an excellent reference.


Finding File Signatures

Considering the focus so far on file signatures, it might be worthwhile to discuss how we actually go about finding what the signature of a file actually is.  

The process of doing this is actually quite straightforward and involves removing different lengths of data from the end of the file and scanning each copy of the file with your AV program of choice to identify which copies of the file are detected as infected.  By manipulating the size of data removed from the end of the file and gradually narrowing down the spot where detection of the file as virus infected stops, you will be able to find the location of the file signature.  This general process was outlined in the Taking Back Netcat paper, and there is also a tool designed specifically for this purpose called DSplit, which you can see in this video here.

Now lets go through each of the modification methods in turn, to describe how they work.


Binary Editing

This is one of the simplest ways in which to avoid antivirus detection, which basically just involves finding the signature of the file and directly changing its contents.  It can be just as easy as my "Pwned" example above.  If the signature is some text within the file, and changing the text won't affect the running of the executable - you can just directly change it within a Hex Editor.  In some cases it will be a little more complicated, and you might need to be able to replace assembly instructions in the file with equivalent instructions.  This is essentially what was done in the Taking Back Netcat paper - nc.exe was opened in OllyDbg and some INT3 instructions from the file signature were replaced with NOPs.  This changed the signature of nc.exe without breaking the application.  This method won't always be effective - the signature may not always include easily changable text or assembly instructions, and in these cases you may need to rely on one of the other methods.


Encoding

This involves encoding the machine language instructions inside an executable, so that these instructions will be decoded in memory before they are run.

A video, with the charming title of "I Piss on Your AV" is located here, and it shows one method of achieving this encoding process.

Essentially, you modify the executable file to add a decoding stub at the end of the file, redirect the programs entry point to this decoding stub, and replace the existing content of the .text section of the PE file with an encoded version.  Then, when the executable is run, the decoder runs first and transforms the content of the .text section of the PE file in memory, before passing control back to this now decoded executable code.  If the file signature was contained within this .text section of the file, it will no longer appear in the file when it is stored on disk - and if the virus scanner only scans the file while it sits on disk then no virus will be detected.

If you want a more detailed version of the process you can do the (highly recommended) Cracking the Perimeter course from Offensive Security.

In the case of Metasploit executables, you can use the method described here to use msfencode for encoding.


Packing

Packing an executable is ostensibly done to reduce its file size, but it can also be quite effective at bypassing antivirus detection, as evidenced by the fact that it is a technique commonly used by malware in the wild.  It has been such a common technique that "unpacking" of executables is a common skill amongst malware reverse engineers, and some malicious software detection tools will trigger on signs that a packer has been used.

Essentially packers work by compressing the contents of an executable file such that it's on disk size is reduced, with the file generally being decompressed in memory when it is run.  Of course, just like with encoded executables, if the signature is part of the data that is compressed when the executable is stored on disk, then any virus scanner that only scans files as they appear on disk will miss it.

There are many types of packers available, and if you are a malware researcher you can see the affect that a few of the most common packers have on a number of well known antivirus engines by using the PolyPack system.  This system is not available to to members of the general public however, so most people will have to do their own dirty work in testing out the various packers available.  There is a list of packers at the PolyPack site, and some of them (such as UPX) are freely available for use.


Source Modification

Modification of the source code of an executable (assuming you have the source and the skill to modify it) can be effective in bypassing virus detection.  Depending on what the signature is this could be as simple as changing the text of some message within the code, or it might be more complicated, requiring the use of different function calls or the reordering of code.

If you are writing the program yourself or have the patience to modify it extensively you can add your own encoding or encryption routines into the code itself, or use polymorphic code.  The important consideration when doing this is that the file signature in the resulting binary file must change as a result of the modification of the source code and the recompilation and linking of the executable.


Recompiling

Sometimes simply recompiling a program with different compiler or linker options, or with a different compiler, can change a files signature and allow you to avoid AV detection.  In my testing of this last year, recompiling Netcat using Visual Studio 2008 bypassed detection by Symantec Antivirus (and also introduced some other minor issues, but that's besides the point).


Use of Alternate Programs

This one is actually a bit of a cheat - instead of changing your desired program to avoid AV detection, simply use another program with similar functionality.

For netcat, some of the following may be suitable:

Can you think of any other methods of modifying a file to avoid AV detection that I may have missed?  Leave a comment...