Microsoft AMSI
CISO Summary
Cofense IntelligenceTM has recently seen a complex phishing campaign that delivers a simple payload, FormGrabber keylogger malware. The targets are Windows 10 operating systems running Windows Anti-malware Scan Interface (AMSI). The phishing emails deliver a Microsoft Excel Worksheet containing a MS Word macro that initiates infection.
What’s notable: threat actors are hitting Windows 10 instead of Windows 7, a more common target. Expect to see greater abuse heaped on the newer version as more businesses adopt it. No one aspect of this campaign is novel, but the attackers easily assembled a complex infection chain using multiple obfuscation and evasion techniques—another sign of how quickly criminals innovate when motivated.
Full Details
Cofense Intelligence recently observed a campaign where threat actors targeted Windows 10 operating systems and used a complex multi-stage campaign to deliver the relatively simple FormGrabber keylogger. The emails utilized a Microsoft Office Excel Worksheet with an Office Word macro to initiate the infection. If macros were enabled, this macro would execute a PowerShell script that compiled embedded C# code content into a .NET dll. The .NET dll was loaded as a PowerShell module that then downloaded and executed the FormGrabber keylogger. The code used in the PowerShell module specifically targets Windows 10 computers which have the Windows Anti-malware Scan Interface (AMSI) installed.
Initiation
Each email identified within this campaign had two attachments: the first was a Microsoft Office Excel Worksheet, the second was an RTF document. This RTF document contained five embedded copies of the same Excel Worksheet, as shown in Figure 1.
Figure 1: Copies of the same embedded Worksheet object
When the document is opened, the victim is prompted five times (once for each of the embedded worksheets) to enable macros. After all the prompts have been responded to, the RTF document will be opened. The method used to embed the worksheet objects into the RTF document requires that the worksheet objects be displayed in some form or fashion. In most cases, threat actors will carefully attempt to hide the object to avoid tipping off victims. As shown in Figure 2, in this case the threat actors simply let the default primary worksheet display in the footer section of the document.
Figure 2: The image displayed in the footer of the RTF document
Here the threat actors repurposed a legitimate example worksheet from Carnegie Mellon University to hide malicious content. The file size and macro run by the attached and embedded Excel worksheets are different, however the end result and final payload location are the same, indicating that the two attachments were likely used for redundancy.
Worksheets
Automated systems often examine the macros in documents in an attempt to determine their intentions. Even if the macro is encoded or obfuscated, modern anti-virus should be capable of reversing the changes or at least detecting key malicious components without running the macro. The macros in these worksheets used a simple technique that may have allowed the threat actors to avoid some automated defenses, crafting a macro that decoded content stored in a cell on a seemingly empty page of the worksheet, as shown in Figure 3. Note that the macro (one line of which appears at the top of the image) references cell “J106” on sheet “RPNLU.” All cells in sheet “RPNLU” appear to be empty and the default page view has cell “J106” out of view, ensuring that even if manually opened, the only obvious discrepancy between the original legitimate worksheet and the malicious one is the addition of the sheet “RPNLU.”
Figure 3: Disguised data used by macro (top of image)
Once decrypted, this macro then launches a PowerShell process which contains another subsection of encrypted data, as shown in Figure 4.
Figure 4: Second stage of the PowerShell script
This PowerShell command takes the encrypted content and decrypts it into C# code, which is then compiled into a .NET dll and loaded as a PowerShell module.
Bypassing
The compilation and multiple layers of encryption involved in this process are all used to “bypass” AMSI. AMSI is a Windows 10 exclusive feature intended to help detect and prevent scripts and “fileless threats.” In order to “bypass” AMSI, the threat actors avoid downloading files and perform other obviously malicious activity in the code that runs in the PowerShell console. Instead they focus only on disabling AMSI by adjusting where it looks for malicious content. The code used for this is similar and almost identical in some places to the proof of concept described in this blog post. Once AMSI is properly disabled, the threat actors then load in the C# code including the explicitly malicious code compiled in a .NET dll as a PowerShell module. A relevant portion of this code can be seen in Figure 5.
Figure 5: A modified version of the original POC code to bypass AMSI
Results and a Look Ahead
Threat actors used a complex infection chain that specifically targeted a key component of Windows 10 operating systems, rather than the more common Windows 7-focused malware, to deliver FormGrabber keylogger. As more businesses switch to the Windows 10 operating system, threat actors, like the ones seen here, can be expected to switch their targets to Windows 10 as well. Although none of the techniques used in this campaign were particularly novel, the fact that it utilized multiple obfuscation and evasion techniques and was so easily assembled from already created work indicates how quickly and significantly threat actors can improve, given the proper impetus. As is usually the case when it comes to vulnerabilities in key components, a patch to prevent this method of AMSI bypass exists. However, businesses first need to be aware of the problem. Knowledge of the evolving threat landscape and the different ways that it can affect a company are key to promoting a secure environment. To improve your security posture, take preventative action by patching systems and training employees to recognize and prevent the first stage in an infection chain.
All third-party trademarks referenced by Cofense whether in logo form, name form or product form, or otherwise, remain the property of their respective holders, and use of these trademarks in no way indicates any relationship between Cofense and the holders of the trademarks.
