Hello folks! Static file analysis techniques have become highly effective, making it unwise to embed the actual malware directly within the initial executable, rather fetch it on runtime. This is why you should have your own loader. Loaders are highly effective at evading static analysis. They come in various forms, including loading DLLs, EXEs, PowerShell scripts, shellcode, and more.
Loaders usually have a specific technique they use. These techniques can be for example APC Queue Code Injection, Thread Hijacking, Process Doppelganging etc. When implemented correctly, these techniques can be highly effective on their own. However, note that some antivirus software may still detect your loader, which is why additional enhancements may be necessary. I will cover some of these add-ons later.
During my time as a malware developer, I have created multiple loaders, but one technique is my personal favorite, Reflective DLL Injection. In Reflective DLL Injection, a DLL is hosted on a server, and the loader fetches it during runtime. Once the data is retrieved, the loader extracts the PE headers and sections of the DLL, such as .data, .rdata and others. After splitting the data into its parts, it calculates the required space for allocation and then performs manual memory mapping. If the DLL is designed to execute on attach, all it needs to do next is to call its entry point, and it will run. The key reason this technique is effective is that it loads the main malware entirely at runtime without ever writing it to disk.
I'd also like to say, for the love of god, do not use Python or .NET to make this stuff. I personally only use C and Powershell for malware. If you do not know how to code yet, or do not know where to start, I'd recommend checking out websites, such as CodeCademy.
Now, once we have a "BETA" version of our loader completed and it still triggers a few detections, what should we do next? Give up? No! Here are some ways to further enhance evasion:
Great additional resources:
~~ Zixshore ~~
Loaders usually have a specific technique they use. These techniques can be for example APC Queue Code Injection, Thread Hijacking, Process Doppelganging etc. When implemented correctly, these techniques can be highly effective on their own. However, note that some antivirus software may still detect your loader, which is why additional enhancements may be necessary. I will cover some of these add-ons later.
During my time as a malware developer, I have created multiple loaders, but one technique is my personal favorite, Reflective DLL Injection. In Reflective DLL Injection, a DLL is hosted on a server, and the loader fetches it during runtime. Once the data is retrieved, the loader extracts the PE headers and sections of the DLL, such as .data, .rdata and others. After splitting the data into its parts, it calculates the required space for allocation and then performs manual memory mapping. If the DLL is designed to execute on attach, all it needs to do next is to call its entry point, and it will run. The key reason this technique is effective is that it loads the main malware entirely at runtime without ever writing it to disk.
I'd also like to say, for the love of god, do not use Python or .NET to make this stuff. I personally only use C and Powershell for malware. If you do not know how to code yet, or do not know where to start, I'd recommend checking out websites, such as CodeCademy.
Now, once we have a "BETA" version of our loader completed and it still triggers a few detections, what should we do next? Give up? No! Here are some ways to further enhance evasion:
- Switch heavily flagged WinAPI calls to NtAPI calls: Replace commonly detected Windows API calls with their corresponding Native API calls. NtAPI functions interact more directly with the Windows kernel and are less commonly monitored or flagged by AVs.
- Do NOT make the loader static; always load necessary components during runtime: Avoid statically linking libraries or functions that can be easily detected by antivirus software. Instead, load the necessary components dynamically during runtime. For instance, if your loader needs to make web requests, do not statically link libraries like winhttp, rather rely on system DLLs that are already pre-installed on Window, such as the winhttp.dll library.
- IAT hooking: You can mess with the import address table in your program. By doing this you can redirect function calls to your own code or change where they go in memory, which makes it harder for tools to figure out what you're doing. You could swap out the addresses in the table with ones that point to your own functions, which might throw off antivirus software and make it look like you're not doing anything shady.
- Strip unnecessary symbols and error information: Minimize the visibility of symbols and debugging information in the final executable. It might even make the executable smaller. I use stripping tools and compiling flags like these, to achieve this: These options will remove debugging symbols, unnecessary sections, and metadata that could be used to analyze or identify the binary.
-g0 -O2 -ffunction-sections -fdata-sections -Wl,--gc-sections -fno-ident -fno-asynchronous-unwind-tables -fno-exceptions -fomit-frame-pointer -s -static-libgcc
- Add small encryption to strings: Add some unadorned "encryption" like XOR (don't complain, I count it as encryption) to your string literals. This makes it harder for antivirus software to identify static patterns in the binary. By using simple encryption (or if possible, preferably your own encoding/encryption), the loader can remain undetected for a longer time, and you can easily modify the encryption key to invalidate the patterns generated by antivirus companies.
- Change function locations and modify static literals: Randomize the placement of functions and modify constant values that are usually hardcoded in the .rodata section. If there are static numbers or plaintext strings in the .rodata section, they're getting saved by the AV instantly and they're easy to identify. Changing their values or their location can make detection even a little bit harder.
- OT/PLT Cleaning: Clean or obfuscate the global offset table and procedure linkage table. These tables are used in dynamically linked programs to resolve addresses for functions at runtime.
Great additional resources:
- https://www.ired.team/offensive-security...T1055/014/
- https://www.crow.rip/crows-nest/mal/dev/...t-syscalls
- https://otterhacker.github.io/
- https://www.ired.team/offensive-security...se-evasion
- https://www.crow.rip/crows-nest/mal/dev/...-injection
- https://github.com/vxunderground/VX-API/
~~ Zixshore ~~
This forum account is currently banned. Ban Length: (Permanent)
Ban Reason: Self-Ban | http://breached26tezcofqla4adzyn22notfqw...an-Appeals if you wish to be unbanned in the future.
Ban Reason: Self-Ban | http://breached26tezcofqla4adzyn22notfqw...an-Appeals if you wish to be unbanned in the future.
