Full Report
Using MS Exchange and Outlook to get a foothold in an organisation, or to maintain persistence, has been a go to attack method for RedTeams lately. This attack has typically relied on using Outlook Rules to trigger the shell execution. Although Ruler makes accomplishing this really easy, it has, up until now, required a WebDAV server to host our shell/application. In most cases this is not an issue, but once in a while you run into a restrictive network that does not allow the initial WebDAV connection to be established. In such instances, the attack sadly fails. Another downside to Outlook rules is that we are limited to only providing an application path, and no command-line arguments, meaning none of our fancy Powershell one-liners can be used.
Analysis Summary
# Tool/Technique: Outlook Forms Shell Execution (via Ruler)
## Overview
This technique leverages Microsoft Outlook's **Custom Forms** feature to execute arbitrary code (VBScript) upon interaction with a message or form, serving as an alternative method to traditional Outlook Rules-based execution, particularly when rules are restricted or if more complex execution logic is desired. The tool **Ruler** is mentioned as facilitating this attack avenue.
## Technical Details
- Type: Technique / Tool (Ruler facilitates the technique)
- Platform: Microsoft Outlook/Exchange Environment (Windows Client)
- Capabilities: Execution of VBScript embedded within custom Outlook Forms triggered by events like form opening, reply creation, or forwarding. Ruler manages the creation, publishing, and retrieval of these malicious forms on the Exchange server/mailbox.
- First Seen: The technique of using Outlook Forms for code execution is described in the context of evolving attacks, building on previous uses of Outlook Rules dating back to at least April 2017 (publication date of the article).
## MITRE ATT&CK Mapping
This attack primarily focuses on initial access or persistence through interaction with the victim's mailbox infrastructure.
- **TA0001 - Initial Access**
- T1566 - Phishing (If the malicious form is delivered via email)
- **TA0003 - Persistence**
- T1533.003 - Data from Information Repositories: Cloud Accounts (If forms are stored within the mailbox/Exchange folder structure)
- **TA0005 - Defense Evasion**
- T1204.002 - User Execution: Malicious File (Related to the initial form interaction)
- **TA0002 - Execution**
- T1204.002 - User Execution: Malicious File (Specifically, executing the embedded VBScript logic)
## Functionality
### Core Capabilities
- **Malicious Form Creation:** Allows embedding VBScript code into Outlook Forms, leveraging the form's `Item_Open` event handler to execute code immediately upon form opening (`calc.exe` demonstrated).
- **Separated Execution Engine:** The VBScript code execution engine in Outlook Forms is separate from the Office VBA Macro engine, meaning disabling macros does not prevent this attack vector.
- **Persistence:** Forms can be published to an Exchange folder (e.g., Inbox), allowing the payload to persist in the mailbox and trigger upon future interactions (e.g., receiving an email with the correct message class).
- **Stealth:** Forms published to Exchange folders are apparently not easily viewable or queryable via standard Exchange management tools or Outlook Web Access (OWA), unlike Outlook Rules.
### Advanced Features
- **Event Triggering:** Unlike previous rule-based limitations which only allowed application path execution, this technique allows customization of the script trigger (e.g., on open, reply, forward).
- **Ruler Integration:** The mentioned tool, **Ruler**, aids in automating the management of these forms via the Exchange protocol, including creation, publishing, retrieval (**display** command), and deletion.
## Indicators of Compromise
The content focuses more on the methodology (forms stored in Exchange tables/folders) rather than specific file hashes for the execution mechanism itself, as the exploit is primarily server-side (via form storage) and client-side (via VBScript execution).
- File Hashes: N/A (Focus on form stored in mailbox)
- File Names: N/A (Focus on form persistence)
- Registry Keys: N/A
- Network Indicators: N/A (Requires communication to Exchange for publishing/retrieval, but no specific external C2 is detailed *other than* the necessary WebDAV requirement previously faced, which this method bypasses in favor of direct mail/form operations).
- Behavioral Indicators:
- Execution of VBScript functions within Outlook in response to message/form events.
- Persistence achieved by custom Outlook Forms being stored in Exchange folders, associated with specific message classes.
## Associated Threat Actors
The article identifies this as a technique used by **RedTeams**. No specific criminal threat group is explicitly named in relation to this evolving technique.
## Detection Methods
- Signature-based detection: Not explicitly defined, likely difficult as it uses native functionality.
- Behavioral detection: Monitoring for VBScript execution originating from unexpected Outlook processes or form handlers.
- YARA rules: Not provided.
## Mitigation Strategies
- **Multi-Factor Authentication (MFA/2FA):** Recommended as a general defense.
- **Monitoring:** Good monitoring and logging should be able to pick up the VBScript execution behavior.
- **GPO/Macro Settings:** Setting **Disable all macros without notification** in Outlook **does not** protect against this VBScript execution vector. Further investigation into disabling the custom form script engine or hardening GPOs is suggested.
## Related Tools/Techniques
- **Ruler:** The tool used to facilitate the creation and management of the malicious Outlook Forms.
- **Outlook Rules:** The predecessor technique this method seeks to bypass or enhance, which previously required a WebDAV server and lacked command-line argument flexibility.