Bypassing Av
Bypassing Av
Abstract
Anti-Virus manufacturers nowadays implements more and more complex functions and algorithms in order to detect the latest and newest viruses along with their variants. There is however simple methods that can be used to bypass most of these, especially those that doesnt use heuristics and similar techniques at all.
Contents
Chapter 1 Introduction ..............................................................................................................2
Chapter 2 PE File Structure ......................................................................................................3 2.1 - AV Signatures and the PE file format ..................................................................................4 2.2 Modifying AV Signatures in PE Files .................................................................................5 2.3 Polymorphic Techniques and Hijacks .................................................................................7
Chapter 3 Encoding Binary Files ..............................................................................................8 3.1 Preparing the PE file for Encoding .....................................................................................9 3.2 Implementing the Custom Encoder ...................................................................................13
Chapter 4 Decoding Binary Files.............................................................................................16 4.1 Altering the Encoder to a Decoder ....................................................................................16 4.2 Testing the Custom Decoder .............................................................................................18
Page 1
Chapter 1
Introduction
Anti-Virus manufacturers has evolved a lot during the last decade, starting with simple signaturebased scanners and thereafter slowly implementing more and more advanced heuristics. Most of these are able to scan files stored on the harddisk, but also opcodes in the memory. Opcodes are in short, Assembly commands which are the lowest level of instructions given to the CPU by any application running. A program is usually developed in a higher level language such as C or C++, where opcodes are usually not directly involved. The compiler on the other hand, translates the high-level code into these opcodes based on the Architecture used and so forth. When a traditional Anti-Virus application scans a file, it does so by reading the offsets and its assigned values. Where the offset is a memory address and the value is an opcode which the scanner can read with a simple binary hex-viewer. Therefore, it is able to look for a signature. If an application passes the file-scan check on the harddisk without any heuristic sandboxes applied, then the file is either safe to run or the Anti-Virus application just got bypassed! This paper will show some of the methods and techniques, one can use in order to do this.
Page 2
Chapter 2
PE File Structure
A typical PE aka Portable Executable which is the default file format for Windows binaries looks like the picture below. It should be mentioned that not all binaries has all these 5 sections. Sometimes its only 4 or perhaps 6-7 sections, depending on how the binary is built / made. The signature which triggers the Anti-Virus application can be located anywhere, though usually it is within one of the actual sections and not section table headers, DOS header, DOS stub etc.
Page 3
Furthermore, the signature is located in the idata section in this case. This means that if we would try to encode the entire idata section, then our executable file might not work at all! Therefore we could try to edit a part of this, or encode only the signature to avoid AV detection.
Page 4
It is however also important to note, that Anti-Virus applications will read the PE headers too and use these to determine whether the executable file we want to run, is malicious or not. Sometimes, even the time and date stamp within the file is a part of the signature which is a good idea to change or simply replace with null. If some of the section tables, headers or flags seem to be invalid by the AV-scanner, then it might flag it as malicious or potentially malicious since it assumes, that it must be due to it cant read the executable file properly.
Page 5
In case ncx99.exe is used as previously mentioned, then it is possible to change both the listening port and the program it will execute. Of course if we change it to e.g. calc.exe then it wont do much good for any hacker at all, but changing the listening port from 99 to e.g. 81 do make a difference. It isnt many AVs that gets fooled by this, but it is a few.
As you can see, Avast and Ikarus were bypassed. If we were to attack a computer which used one of these, then we wouldve succeeded now just by changing the listening port.
Page 6
Hijacks
In case we want to encode it, we have to hijack the entry point of the binary file either by editing the PE headers or perhaps by overwriting the first instruction to a jump, which then points to a code cave which is an unused section of data, where a hacker can enter his own code without altering the size of the target file. It should be noted though, that some AVs actually checks the file-size too. The hacker can of course, overwrite instructions further inside the binary too if he or she desires to do so. As long as the original program still contains the same functionality, in order to execute without crashing or causing similar errors, then it doesnt matter where any edits are made.
Page 7
Chapter 3
Before Alteration
After Alteration
Entry Point
Ncx99.exe
Ncx99.exe
Signature
Signature
Assembly Encoder
Page 8
First we select the first couple of instructions (opcodes) and copy them to notepad or whatever program we prefer for taking notes. The reason why were doing this is because we need to reintroduce some of the first overwritten opcodes later on, before we re-route the execution flow back to its original place.
Page 9
We now have the following opcodes saved which we will need later on:
Address 00404C00 00404C01 00404C03 00404C05 00404C0A 00404C0F 00404C15 Hex /. |. |. |. |. |. |. dump 55 8BEC 6A FF 68 00B04000 68 78764000 64:A1 0000000 50 Command PUSH EBP MOV EBP,ESP PUSH -1 PUSH OFFSET 0040B000 PUSH 00407678 MOV EAX,DWORD PTR FS:[0] PUSH EAX
Then we browse through the binary, for a convenient place to implement our custom encoder. After searching for a while inside the .text data section, we may find the following place.
Page 10
After weve noted down the new Entry Point address at 0040A770, we browse to the memory overview by clicking the M icon. Then we double-click on the PE Header section and open it. Simply, because we need to prepare the .text data section by making it writeable and of course, change the old Entry Point to our new one, which points to our code cave. Adding a few bytes extra to the last section doesnt hurt either, as this may bypass some AV-scanners.
This is the value we need to edit in order to be able to make the .text section writeable. We could use LordPE for this, but knowing the common values by mind, makes us able to do this without. We will therefore change 60000020 to E0000020 as shown in the next picture, making the .text section writeable, allowing us to encode this while the PE file is executing. If we didnt do this we would get a permission error and most likely crash.
Page 11
Adding a few bytes to one of the sections is a good idea too, if you dont need to be very strict on keeping exactly the same file-size. This is done by taking the hexadecimal value of e.g. the .idata section and then add the number of bytes wanted in hex. If youre going to do this, then make sure youre calculating in hex and not decimal.
After weve made our modifications, we select the entire section which contains our changes, right click and browse to Edit, and then Copy to Executable. Then right click on the new window and choose Save File. Keep in mind that this is a bit different in the older version of Ollydbg.
Page 12
Because weve added a few bytes to the .idata section, the program wont execute. Therefore we need to add the amount of bytes we added, by using a hex-editor to add the actual amount of bytes that was added to the .idata section.
In this case XVI32 (a hex-editor) is sufficient to use. Simply browse to the end of the PE file, open the Edit menu and choose Insert string. Then make sure you either add 00, 90 or CC. Preferably just add 00 as this will do nothing at all. Under Insert <n> times you choose hexadecimal and choose the amount of bytes you added to the .idata section. When youre done click the save icon and your executable PE file, should be working again.
Page 13
Command MOV EAX,00401000 ADD BYTE PTR DS:[EAX],13 XOR BYTE PTR DS:[EAX],0F ADD BYTE PTR DS:[EAX],37 INC EAX CMP EAX,0040A76F JLE SHORT 0040A775
Page 14
With our custom encoder implemented were almost done. It should be noted, that we could also use other opcodes too, to encode our .text section. Such opcodes could be: sub, or, and, etc. But for now were going to re-introduce some of the first few opcodes that was originally run by the executable in the start. Now we could be simple and just place a jump to 00404C00, but well add the first couple of instructions ourselves as shown in the picture below.
With that done you may wonder what the JMP 00404C05 opcode is. That is a jump to the offset aka memory address where the next instruction after the original PUSH -1 is located. It should be noted that if we were to execute the file now, it would simply fail because the PE file as it is right now, will encode the .text section and try to execute it. Since it becomes encoded, then it will most likely fail and crash. But save the changes anyway and re-open it. This is because we first need to use our encoder, to encode the file and afterwards change it to a decoder, so the execution flow will seem completely normal even without a debugger.
Page 15
Chapter 4
Page 16
We will still use the add opcode and of course xor, but well only need to change the values as mentioned previously, which you can also see in the picture above in figure 4.1.1. When weve done that we copy our changes to an executable, and save it as a new file. In theory the PE file should work now just as it did to start with, but it is also encoded too making it able to bypass some AV-scanners, which makes it more interesting.
Page 17
In the picture above, only the first hex character has been decoded back to its original state. (Please note that a character in this case, is a byte which is the same as 8 bits made of binary.) By placing a breakpoint right after JLE SHORT 0040A775, and then running the PE file until it stops executing, well see that the entire .text section has changed back to its original state. If we execute the first couple of re-introduced opcodes including the long jump back to where the real start of the program is, well see that it may still look obfuscated or encoded.
Page 18
This does not really matter, as we can hit CTRL+A and do a quick analysis of the code. When weve done that we may see that our executable PE file is back to its original state again and if we press F9 we may see that our program is executing without any errors. If that is the case then weve encoded the binary file and even decoded it successfully. Even scanning the file now with a lot of different AV-scanners will reveal different results, if the file is just scanned and not executed since we havent implemented any bypassing techniques for heuristic (malicious) opcode detection.
Page 19
If we scan the file with AVG it may be undetectable now, or as script kiddies tends to say: FUD. This expression means Fully Undetectable and is widely used with tools such as cryptors. Most of these use another way of making the PE files able to bypass the AV-scanners, which is e.g. by encrypting the entire file with RC4 and then pack a stub decoder into the file. This will of course alter the size of the file in many cases. In the picture below youll see that many of the AVs either didnt know what was scanned or they didnt flag it as malicious at all.
Page 20
Chapter 5
Conclusion
The purpose of this paper was to demonstrate how easy it is to bypass signature-based AntiVirus scanners which do not use heuristics at all or perhaps only in an insufficient way which makes a hacker able to outsmart the AV-system in use.
As you can see almost all of the AV-scanners detects the original ncx99.exe by default.
Page 21
If we alter this file heavily then the results are quite amazing. The amount of code added and changed can be as little as below 30 bytes which is the equivalent of 30 characters you can type on your keyboard. Even the size of the file may have been unaltered too, though the contents of the file may have been encoded with a custom encoder.
As you can see for yourself in the picture above, a lot of the AV-scanners were bypassed. Kaspersky detected this file as potentially malicious with its heuristics system, hence the reason Type_Win32 is stated which means it is probably a new variant of a virus, trojan, etc. In any case it is always a good idea to encode the primary signature of the file, though usually there is more than one signature so it isnt piece of cake for any hacker to bypass AV-detection.
Page 22
References
[1] http://www.intern0t.net [2] http://www.ollydbg.de/ [3] http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm [4] http://debugger.immunityinc.com/ [5] https://forum.immunityinc.com/board/show/0/ [6] http://free.avg.com/ww-en/homepage [7] http://www.uninformed.org/?v=5&a=3&t=pdf [8] http://www.offensive-security.com
Page 23