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

This article will explain in detail how to identify and analyze anti-malware scanning interface AMSI components. The content of the article is of high quality, so the editor shares it for you as a reference. I hope you will have some understanding of the relevant knowledge after reading this article.

AMSI provides rich interfaces for terminal security vendors to help them better scan the memory buffer of the target component, or select what needs to be scanned. According to the information provided by Microsoft, the following components are supported by AMSI:

1. User account Control (UAC)

2. PowerShell (scripting, interactive use, and dynamic code calculation)

3. Windows script host (wscript.exe and cscript.exe)

4. JavaScript and VBScript

5. Office VBA macro

For engineers and defenders engaged in security defense testing, as well as attack-side researchers interested in mature avoidance technologies, I ask you the following questions:

1. Which actual PE files are associated with the components supported by AMSI?

2. Is the information provided by Microsoft accurate, or what components are missing from the above list?

3. Is it possible to use AMSI without registering AMSI programs as terminal security providers?

AMSI component enumeration

To solve the first two problems, we need to find a way to automatically identify and discover AMSI components. The whole process involves a series of EXE or DLL files that contain the ASCII or Unicode string "amsi.dll". So why are we searching for the "amsi.dll" string?

1. Amsi.dll can provide the functions needed to scan the buffer, namely AmsiScanBuffer, AmsiScanString, and AmsiUacScan.

2. This string means that EXE or DLL can be statically imported (for example, it can be stored in a PE file as an ASCII string) or dynamically loaded at run time (for example, it can be stored in a PE file as a Unicode string) amsi.dll.

The following PowerShell code may answer our questions:

$UserPEs = Get-CimInstance-ClassName CIM_DataFile-Filter 'Drive = "C:" and (Extension = "exe" or Extension = "dll")'-Property 'Name' | Select- ExpandProperty Name$AMSIReferences1 = $UserPEs |% {Select-String-Encoding ascii-LiteralPath $_-Pattern' amsi\ .dll'} $AMSIReferences2 = $UserPEs |% {Select-String-Encoding unicode-LiteralPath $_-Pattern 'amsi\ .dll'} $AMSIReferences1.Path$AMSIReferences2.Path

The above PowerShell snippet uses WMI to enumerate all EXE and DLL. This method is chosen over Get-ChildItem because it is possible to throw an exception when trying to access a file that it does not have access to.

Next, it uses Select-String (the equivalent of grep in PowerShell) to scan each file and look for the ASCII and Unicode text strings in the file-"amsi.dll".

After filtering the results, the following AMSI components are found:

1.% windir%\ System32\ consent.exe

2.% windir%\ System32\ jscript.dll

3.% windir%\ System32\ vbscript.dll

4.% windir%\ System32\ wbem\ fastprox.dll

5.% windir%\ Microsoft.NET\ assembly\ GAC_MSIL\ System.Management.Automation\ v4.0_3.0.0.0__31bf3856ad364e35\ System.Management.Automation.dll

6.% windir%\ Microsoft.NET\ Framework64\ v4.0.30319\ clr.dll

7.% ProgramFiles%\ WindowsApps\ Microsoft.Office.Desktop_16051.11929.20300.0_x86__8wekyb3d8bbwe\ VFS\ ProgramFilesCommonX86\ Microsoft Shared\ VBA\ VBA7.1\ VBE7.DLL

After the research, we classify the above AMSI components according to the documentation provided by Microsoft:

1. User account control: consent.exe

2 、 PowerShell:System.Management.Automation.dll

3. JavaScript and VBScript:jscript.dll, vbscript.dll

4. Office VBA macro: VBE7.dll

5. Unclassified: clr.dll, fastprox.dll

What are these unclassified AMSI components? Clr.dll, the common language runtime, was mentioned by Microsoft in .NET 4.8.Its role is to scan for compiled loads in memory. At present, some researchers have been studying the related bypass mechanism, and see the references at the end of this article. Next we will analyze the fastprox.dll, we are not in a hurry.

WMI and AMSI

Fastprox.dll is located in the System32\ wbem directory, and fastprox.dll is described as "WMI custom Marshaller". It goes without saying that it is obviously related to WMI. For further verification, we can use PowerShell to identify which process the loading of fastprox.dll is related to:

> Get-Process | Where-Object {$_ .Modules.ModuleName-contains' fastprox.dll'} Handles NPM (K) PM (K) WS (K) CPU (s) Id SI ProcessName- 2196 274 219988 232044 14573.92 1192 5 chrome 1162 47 85544 38524 803.86 14580 5 mmc 692 42 129920 55564 1081.20 2408 5 powershell 874 47 77144 87852 73.48 4040 5 powershell 686 39 71132 42608 42.78 12620 5 powershell 229 13 2596 10072 0.13 2956 0 svchost 480 20 3840 6728 69.66 3376 0 svchost 613 34 26776 17356 4370.64 3648 0 svchost 217 43 2572 4148 18.64 6728 0 svchost 564 33 11276 16544 4.34 11520 0 svchost 129 7 1496 2196 0.77 5232 0 unsecapp 1650 67 318004 256536 99.28 16576 5 vmconnect 898 29 62664 23660 1267.36 4776 0 vmms 386 16 8492 13408 21.77 14220 0 WmiPrvSE 176 10 2684 8592 1.36 15772 0 WmiPrvSE

We can use the following PowerShell command to parse the service corresponding to the svchost.exe process:

> Get-Process | Where-Object {$_ .Modules.ModuleName-contains' fastprox.dll'-and $_ .ProcessName-eq 'svchost'} | ForEach-Object {Get-CimInstance-ClassName Win32_Service-Filter "ProcessId = $($_ .Id)"} | Format-Table-AutoSizeProcessId Name StartMode State Status ExitCode -2956 Netman Manual Running OK 03376 iphlpsvc Auto Running OK 03648 Winmgmt Auto Running OK 06728 SharedAccess Manual Running OK 011520 BITS Auto Running OK 0

From this point of view, it seems that any process that wants to interact with WMI needs to use this DLL. Now, let's look directly at the code to determine how fastprox.dll interacts with amsi.dll. Currently, the only "amsi.dll" reference appears in the JAmsi::JAmsiInitialize function, and here is the code:

First, this function initializes AMSI only if the current process is not% windir%\ System32\ wbem\ wmiprvse.exe. After parsing the call to loadlibrary in amsi.dll and the required related export functions (such as amsiscanbuffer), we find that the only cross-reference to amsiscanbuffer is the JAmsi::JAmsiRunScanner function:

JAmsiRunScanner is called by JAmsi::JAmsiProcessor, and this function is called by the following function:

1. CWbemSvcWrapper::XWbemServices::ExecNotificationQueryAsync2, CWbemSvcWrapper::XWbemServices::CreateInstanceEnum3, CWbemSvcWrapper::XWbemServices::ExecQueryAsync4, CWbemSvcWrapper::XWbemServices::ExecQuery5, CWbemSvcWrapper::XWbemServices::CreateInstanceEnumAsync6, CWbemSvcWrapper::XWbemServices::GetObjectW7, CWbemSvcWrapper::XWbemServices::ExecMethod8, CWbemSvcWrapper::XWbemServices::ExecMethodAsync9, CWbemSvcWrapper::XWbemServices::ExecNotificationQuery10, CWbemSvcWrapper::XWbemServices::GetObjectAsync11, JAmsi::JAmsiProcessor (called by CWbemInstance::SetPropValue)

Except for the last function, all the other functions correspond to the methods implemented by the IWbemServices interface, and the last function probably corresponds to the IWbemClassObject::Put method.

Next, we need to run logman to capture all AMSI events and try to capture related WMI events:

Logman start trace AMSITrace-p Microsoft-Antimalware-Scan-Interface (Event1)-o amsi.etl-ets

Next, run the following code for the event trigger test:

$CimSession = New-CimSession-ComputerName. Invoke-CimMethod-ClassName Win32_Process-MethodName Create-Arguments @ {CommandLine = 'notepad.exe'}-CimSession $CIMSession$CIMSession | Remove-CimSession

The above command creates a local CIM session to enumerate remote WMI connections, and after completing the WMI interaction, stop event capture:

Logman stop AMSITrace-ets

Next, use PowerShell to identify any WMI event:

> $AMSIEvents = Get-WinEvent-Path.\ amsi.etl-Oldest > $AMSIEvents [5] | Format-List * Message: AmsiScanBufferId: 1101Version: 0Qualifiers: Level: 4Task: 0Opcode: 0Keywords:-9223372036854775807RecordId: 5ProviderName: Microsoft-Antimalware-Scan-InterfaceProviderId : 2a576b87-09a7-520e-c21a-4942f0271d67LogName: ProcessId: 7184ThreadId: 8708MachineName: COMPY486UserId: TimeCreated: 10 PMActivityId: 2019 12:14:51 PMActivityId: 95823c06-72e6-0000-a133-8395e672d501RelatedActivityId: ContainerLog: C:\ users\ testuser\ desktop\ amsi.etlMatchedQueryIds: {} Bookmark : System.Diagnostics.Eventing.Reader.EventBookmarkLevelDisplayName: InformationOpcodeDisplayName: InfoTaskDisplayName: KeywordsDisplayNames: {} Properties: {System.Diagnostics.Eventing.Reader.EventProperty System.Diagnostics.Eventing.Reader.EventProperty...} > $AMSIEvents [5]. PropertiesValue-011WMI300300 {67,0,73,0.} {131,136,119,209.} False > [Text.Encoding]:: Unicode.GetString ($AMSIEvents [5] .Properties [7] .value) CIM_RegisteredSpecification.CreateInstanceEnum () Win32_Process.GetObjectAsync (); Win32_Process.GetObject (); SetPropValue.CommandLine ("notepad.exe"); > Get-CimInstance-ClassName Win32_Service-Filter "ProcessId = $($AMSIEvents [5] .ProcessId)" ProcessId Name StartMode State Status ExitCode--7184 WinRM Auto Running OK 0

First, the sixth event (index 5) is the only event with "wmi" in the value of the fourth attribute. In addition, the eighth attribute value contains binary data that looks like a Unicode string. After decoding, it reflects the execution of win32_process create in the above example. It is worth noting that the logged process ID-7184 is the source of the AMSI event, which is a svchost.exe process.

WMI is very "confusing", the operating system will regularly use WMI for legitimate operations, while suspicious operations will also involve WMI, and many WMI operations will not be recorded. The reason behind this is obvious, because JAmsi::JAmsiRunScanner executes only when JAmsi::JAmsiIsScannerNeeded returns TRUE.

WMI's operation context string has a specially calculated CRC checksum, and WMI events are logged only if their checksum matches the values in the whitelist:

In the course of the study, we found that the whitelist included the following CRC checksums:

0x788c9917 、 0x96b23e8a 、 0xb8da804e 、 0xc0b29b3d 、 0xd16f4088 、 0xd61d2ea7 、 0xef726924 、 0x46b9d093 、 0xf837efc3

Obviously, as long as attackers can restore the checksum in the whitelist, they can bypass the operating system's record of WMI operations, and you must know the result!

On how to identify and analyze anti-malware scanning interface AMSI components to share here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

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.