AMSI, one step further from Windows malware detection

At the beginning it was a virus; pieces of assembly code which connected to the files, so that they could modify the “entrypoint”. Afterwards, this technique was twisted and improved as much as possible, they searched for automatic execution, reproduction, and independence of the “guest” (the malware has already beenstandalone since some time), and also so that it could go under the antivirus radar. “Touch Hard Disk” was the premise (how could they infect it?) and in turn the malware anathema. If it managed to avoid this toll as much as possible, it could get away from the detectors. This technique is called “Fileless”, which sought for an ethereal formula in order to survive within the memory for as long as possible. Hence, it does not touch the disk or delay it too much and it does not land upon what the antivirus firmly controls. “Fileless” has been perfected to such an extent (are you familiar with the malware which combines macros and Powershell?), that there is already a native formula in Windows to mitigate it as much as possible. Yet, it’s not getting the attention that it should.

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.

The provider model is established; by which you can make the flow pass on the information. The provider will be the one which receives the flow; this role should be fulfilled by whatever has the capacity to analyze this flow as if it were a file, or even, an antivirus. At the same time, AMSI facilitates that any developer can solicit their code that goes through AMSI by a certain “input”. For example, a script for Powershell (something which Windows already does) or a code JavaScript from a navigator. Would it not be interesting if Chrome or Firefox were to pass by AMSI a piece of JavaScript before launching it, without it even touching a temporary folder? Yes, in theory it is possible, the only thing is that still no one does it in this native way. So who does it? Fundamentally, the Microsoft scripting tools; and amongst them, one of the most necessary, Powershell. Ever since roughly 2015, the malware based upon Powershell became popular, a movement in this direction was seen as necessary. With AMSI, the interpreter launches the flow to be analyzed first by the corresponding provider. As the default provider is the very own Windows Defender, its detection capacity is what it is. Though, if an antivirus were to act as an AMSI provider it could manage to evaluate the code which did not pass by the hard drive, since it is simply in the form of an information “flow”.

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.