|The basic AMSI structure, provided by Microsoft|
Anti-Malware Scan Interface (AMSI), basically, seeks to solve a serious lifetime problem within the antivirus industry, which is to detect what does not “touch the hard disk”. It was introduced within Windows 10 and deals with establishing a native communication channel from an operating system which “goes through an antivirus” without the need to “hack” disk, I/O calls, etc. Any flow can pass by this detector, even the very obfuscated called scripts which evaluate and reconstruct their malicious charge within the memory. AMSI comes as standard for Windows and includes a facility so that:
- Any programmer can order it to analyze the program’s input flows which they find in the memory.
- Anyone can analyze this flow, by establishing it as an analysis provider (such as an antivirus)
In a world where they still infect systems thanks to any blatant “fileless” trick of obfuscation, this tool is more than necessary.
|AMSI in Powershell (source available here)|
From the most attractive possibilities (beyond Microsoft’s own scripting software which already does it), we have thought about the advantages for a world in which, in a native way, the content of the navigator as a ‘flow’ can be evaluated by a traditional antimalware system by firms. The antivirus could reach a lot further, and it would not even have to be worried about having to put itself inside the traffic, to wait for it to be stored in the information, to detect the ‘miners’on the fly, etc. Ultimately, it offers an antivirus which supports AMSI (but for now, as far as we know, few appear to support it: AVG/Avast, Dr.Web, ESET…), to hook itself onto the scripts’ interpretations, which we assume would improve or facilitate the detection capacity.
It is very simple, imagine this Powershell line is observed from with inside the image and remotely downloads a MimiKatz instance (software habitually used to show memory credentials, and detected by many antimalware systems). A download and execution through Powershell without really storing the information, ends up being detected by its own Windows Defender. It’s actually Windows Defender through AMSI which has interrupted this case.
|AMSI in action when it invokes a ‘downloaded’ script|
On the other side, what we do is actually download this ps1 file from Mimikatz in a hard disk and it will be Windows Defender who directly detects it. In the logs it is very clear. To the left of the generated event with the first invocation with Webclient. To the right, the generated event with the second saved in the disk.
|On the left, it is detected with the intent of downloading. On the right, it is detected when it is stored as a file.|
Of course, like everything else; it is avoidable in the sense that it does not pass through it, or invalidate itself in any way. We are not speaking about false positives, given that AMSI itself does not detect anything, as it is a simple channel or messenger. The following list which we show maybe does not include all of the found possibilities which can be used to deactivate or avoid it, but overall it provides the majority.
- Using COM hijacking: this formula was released in mid 2017 and has already been solved by Microsoft. AMSI searches for a COM object (CLSID) first in HKCU (where it did not used to exist), then it searched in HKLM where it actually was. If this CLSID is created within HKCU first, the successful initialization of AMSI was prevented.
- Using a nullbyte: it was released in February 2018 and has already been solved by Microsoft. It consisted of adding a traditional null byte before the detected chain, which was malicious due to the potential viruses. AMSI utilizes strncpy whose function was copied into the buffer to scan it, until it is found by a 0. A flaw which is quite unacceptable right now. More information can be found here..
- Memorypatching: was also released in February this year and has already been solved by Microsoft. It consisted of a memory patch for the AmsiScanBuffer() function which should be executed in Powershell before the malicious script is executed. More information about this technique is available at Black Hat Asia.
There are other ways to avoid it, such as the ones shown here, as well as examples where it is disabled in some way, or it tries to avoid flow detection. We have various examples within this talk.
AMSI along with other security measures embedded as standard in Windows 10, could be implemented better or worse, more or less usable, liked a little or a lot, that result useful or not. However, the security measures (now all grouped together in Windows 10, under the same umbrella of Device Guard, with its kind of EMET, antivirus, CFG, firewall outside, the old AppLocker…) they are there by default, this is a fact, and it is necessary to get to know them well in order to take advantage of them and in turn improve overall security. AMSI is one of the most interesting tools, and at the same time one of the less well known.
Innovation and Laboratory Team at ElevenPaths
Innovation and Laboratory Team at ElevenPaths