#TIFG: AMSI

Friday, December 20, 2019

Introduction

In my never-ending list of thingsthatconfusemeaboutwindows, I’ve added a new one.

AMSI.

As per the usual structure with these writeups, I won’t be diving into how to pull apart the entire process. Its merely an introductory to the concept that I can reference from future projects.

Overview

AMSI is the Windows Antimalware Scan Interface. Its a self-described versatile interface standard that can allow for an application/service to integrate with any antimalware product that’s present on a machine.

Additionally, AMSI doesn’t care about what AV is in place. Its designed to allow for the most common malware scanning and protection techniques provided by current antimalware products. AMSI supports a calling structure which can allow for file and memory or stream scanning, content source URL/IP reputation checks, and other techniques. 1

There are a couple of different components that are integrated with AMSI:

  • UAC
  • PowerShell
  • Scripting languages: wscript, cscript, JavaScript and VBScript
  • Office VBA macros

AMSI works by analyzing scripts before they are executed to determine if it is malicious. It’s designed to detect obfuscated malware by being called recursively on every evaluation step. This makes more sense when you think of a payload being decoded and decompressed in memory until the final payload is ready to be executed 2.

Here is what the AMSI architecture looks like:

AMSI Architecture

To give this some context, here is how AMSI would step through the execution of some PowerShell 3

  • A PowerShell script is launched. Thus, a process is created. AMSI.DLL is then loaded into the processes address space.
  • AmsiScanBuffer() will then recursively assess the the script before it is executed.
  • AmsiScanBuffer() will the check if any signatures have been created.

At this point, AMSI will know if the file is malicious or not.

As a test case, I’ll run this code4:

$base64 = "FHJ+YHoTZ1ZARxNgUl5DX1YJEwRWBAFQAFBWHgsFAlEeBwAACh4LBAcDHgNSUAIHCwdQAgALBRQ="
$bytes = [Convert]::FromBase64String($base64)
$string = -join ($bytes | % { [char] ($_ -bxor 0x33) })
iex $string

If it is malicious, Windows will complain:

iex : At line:1 char:1
+ 'AMSI Test Sample: 7e72c3ce-861b-4339-8740-0ac1484c1386'
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This script contains malicious content and has been blocked by your antivirus software.
At C:\evil.ps1:4 char:1
+ iex $string
+ ~~~~~~~~~~~
    + CategoryInfo          : ParserError: (:) [Invoke-Expression], ParseException
    + FullyQualifiedErrorId : ScriptContainedMaliciousContent,Microsoft.PowerShell.Commands.InvokeExpressionCommand

A file is only considered malicious when the signature has been logged. Due to this, its somewhat easy to bypass. So, by simply changing evil-script.ps1 to:

"Evil"+"Script"+".ps1"

Will completely change the signature and bypass AMSI.

Bypassing AMSI

as of now, I won’t be discussing the bypasses, I’ll save that for a later post. I stated at the start of this that I just wanted a small overview of what AMSI actually was, which I think I have achieved.

Additional reads:

Conclusion

As an overview to the service, I think this will suffice. As I’ve stated, further research into bypassing AMSI can be done. But, this will serve as a referable writeup which will likely expand as I do more research into AMSI.

References


  1. Antimalware Scan Interface (AMSI) ↩︎

  2. Antimalware Scan Interface (AMSI) — A Red Team Analysis on Evasion ↩︎

  3. Hunting for AMSI bypasses ↩︎

  4. How the Antimalware Scan Interface (AMSI) helps you defend against malware ↩︎

WindowsAMSI

Net-NTLM Relaying

#TIFG: NT (New Technology) LAN Manager