{
	"id": "bff8bd94-3a27-44a4-8cef-9fbadefdf89e",
	"created_at": "2026-04-06T00:19:38.972976Z",
	"updated_at": "2026-04-10T13:12:57.044523Z",
	"deleted_at": null,
	"sha1_hash": "c71de28ecea948157d1f84e3bc8e38a944762f2e",
	"title": "Detect and remediate the Outlook rules and custom forms injections attacks. - Microsoft Defender for Office 365",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 100061,
	"plain_text": "Detect and remediate the Outlook rules and custom forms\r\ninjections attacks. - Microsoft Defender for Office 365\r\nBy chrisda\r\nArchived: 2026-04-05 22:58:28 UTC\r\nSummary Learn how to recognize and remediate the Outlook rules and custom Forms injections attacks in Office\r\n365.\r\nAfter an attacker gains access to your organization, they try to establish a foothold to stay in or get back in after\r\nthey're discovered. This activity is called establishing a persistence mechanism. There are two ways that an\r\nattacker can use Outlook to establish a persistence mechanism:\r\nBy exploiting Outlook rules.\r\nBy injecting custom forms into Outlook.\r\nReinstalling Outlook, or even giving the affected person a new computer doesn't help. When the fresh installation\r\nof Outlook connects to the mailbox, all rules and forms are synchronized from the cloud. The rules or forms are\r\ntypically designed to run remote code and install malware on the local machine. The malware steals credentials or\r\nperforms other illicit activity.\r\nThe good news is: if you keep Outlook clients patched to the latest version, you aren't vulnerable to the threat as\r\ncurrent Outlook client defaults block both mechanisms.\r\nThe attacks typically follow these patterns:\r\nThe Rules Exploit:\r\n1. The attacker steals a user's credentials.\r\n2. The attacker signs in to that user's Exchange mailbox (Exchange Online or on-premises Exchange).\r\n3. The attacker creates a forwarding Inbox rule in the mailbox. The forwarding rule is triggered when the\r\nmailbox receives a specific message from the attacker that matches the conditions of the rule. The rule\r\nconditions and message format are tailor-made for each other.\r\n4. The attacker sends the trigger email to the compromised mailbox, which is still being used as normal by\r\nthe unsuspecting user.\r\n5. When the mailbox receives a message that matches the conditions of rule, the action of the rule is applied.\r\nTypically, the rule action is to launch an application on a remote (WebDAV) server.\r\n6. Typically, the application installs malware on the user's machine (for example, PowerShell Empire).\r\n7. The malware allows the attacker to steal (or steal again) the user's username and password or other\r\ncredentials from local machine and perform other malicious activities.\r\nThe Forms Exploit:\r\nhttps://docs.microsoft.com/en-us/office365/securitycompliance/detect-and-remediate-outlook-rules-forms-attack\r\nPage 1 of 7\n\n1. The attacker steals a user's credentials.\r\n2. The attacker signs in to that user's Exchange mailbox (Exchange Online or on-premises Exchange).\r\n3. The attacker inserts a custom mail form template into the user's mailbox. The custom form is triggered\r\nwhen the mailbox receives a specific message from the attacker that requires the mailbox to load the\r\ncustom form. The custom form and the message format are tailor-made for each other.\r\n4. The attacker sends the trigger email to the compromised mailbox, which is still being used as normal by\r\nthe unsuspecting user.\r\n5. When the mailbox receives the message, the mailbox loads the required form. The form launches an\r\napplication on a remote (WebDAV) server.\r\n6. Typically, the application installs malware on the user's machine (for example, PowerShell Empire).\r\n7. The malware allows the attacker to steal (or steal again) the user's username and password or other\r\ncredentials from local machine and perform other malicious activities.\r\nUsers are unlikely to notice these persistence mechanisms and they might even be invisible to them. The following\r\nlist describes the signs (Indicators of Compromise) that indicate remediation steps are required:\r\nIndicators of the Rules compromise:\r\nRule Action is to start an application.\r\nRule References an EXE, ZIP, or URL.\r\nOn the local machine, look for new process starts that originate from the Outlook PID.\r\nIndicators of the Custom forms compromise:\r\nCustom forms present saved as their own message class.\r\nMessage class contains executable code.\r\nTypically, malicious forms are stored in Personal Forms Library or Inbox folders.\r\nForm is named IPM.Note.[custom name].\r\nYou can use either of the following methods to confirm the attack:\r\nManually examine the rules and forms for each mailbox using the Outlook client. This method is thorough,\r\nbut you can only check one mailbox at a time. This method can be very time consuming if you have many\r\nusers to check, and might also infect the computer that you're using.\r\nUse the Get-AllTenantRulesAndForms.ps1 PowerShell script to automatically dump all the mail\r\nforwarding rules and custom forms for all the users in your organization. This method is the fastest and\r\nsafest with the least amount of overhead.\r\n1. Open the users Outlook client as the user. The user may need your help in examining the rules on their\r\nmailbox.\r\n2. Refer to Manage email messages by using rules article for the procedures on how to open the rules\r\ninterface in Outlook.\r\n3. Look for rules that the user didn't create, or any unexpected rules or rules with suspicious names.\r\nhttps://docs.microsoft.com/en-us/office365/securitycompliance/detect-and-remediate-outlook-rules-forms-attack\r\nPage 2 of 7\n\n4. Look in the rule description for rule actions that start and application or refer to an .EXE, .ZIP file or to\r\nlaunching a URL.\r\n5. Look for any new processes that start using the Outlook process ID. Refer to Find the Process ID.\r\n1. Open the user Outlook client as the user.\r\n2. Follow the steps in, Show the Developer tab for the user's version of Outlook.\r\n3. Open the now visible developer tab in Outlook and select design a form.\r\n4. Select the Inbox from the Look In list. Look for any custom forms. Custom forms are rare enough that if\r\nyou have any custom forms at all, it is worth a deeper look.\r\n5. Investigate any custom forms, especially forms marked as hidden.\r\n6. Open any custom forms and in the Form group, select View Code to see what runs when the form is\r\nloaded.\r\nThe simplest way to verify a rules or custom forms attack is to run the Get-AllTenantRulesAndForms.ps1\r\nPowerShell script. This script connects to every mailbox in your organization and dumps all the rules and forms\r\ninto two .csv files.\r\nYou need to be a member of the Global Administrator* role in Microsoft Entra ID or the Organization\r\nManagement role group in Exchange Online, because the script connects to every mailbox in the organization to\r\nread rules and forms.\r\nImportant\r\n*\r\n Microsoft strongly advocates for the principle of least privilege. Assigning accounts only the minimum\r\npermissions necessary to perform their tasks helps reduce security risks and strengthens your organization's\r\noverall protection. Global Administrator is a highly privileged role that you should limit to emergency scenarios or\r\nwhen you can't use a different role.\r\n1. Use an account with local administrator rights to sign in to the computer where you intend to run the script.\r\n2. Download or copy the contents of the Get-AllTenantRulesAndForms.ps1 script from GitHub to a folder\r\nthat's easy to find and run the script from. The script creates two date stamped files in the folder:\r\nMailboxFormsExport-yyyy-MM-dd.csv and MailboxRulesExport-yyyy-MM-dd.csv .\r\nRemove lines 154 to 158 from the script, because that connection method no longer works as of July 2023.\r\n3. Connect to Exchange Online PowerShell.\r\n4. Navigate in PowerShell to the folder where you saved the script, and then run the following command:\r\n.\\Get-AllTenantRulesAndForms.ps1\r\nhttps://docs.microsoft.com/en-us/office365/securitycompliance/detect-and-remediate-outlook-rules-forms-attack\r\nPage 3 of 7\n\nMailboxRulesExport-yyyy-MM-dd.csv: Examine the rules (one per row) for action conditions that include\r\napplications or executables:\r\nActionType (column A): The rule is likely malicious if this column contains the value\r\nID_ACTION_CUSTOM .\r\nIsPotentiallyMalicious (column D): The rule is likely malicious if this column contains the value\r\nTRUE .\r\nActionCommand (column G): The rule is likely malicious if this column contains any of the\r\nfollowing values:\r\nAn application.\r\nAn .exe or .zip file.\r\nAn unknown entry that refers to a URL.\r\nMailboxFormsExport-yyyy-MM-dd.csv: In general, the use of custom forms is rare. If you find any in this\r\nworkbook, open that user's mailbox and examine the form itself. If your organization didn't put it there\r\nintentionally, it's likely malicious.\r\nIf you find any evidence of either of these attacks, remediation is simple: just delete the rule or form in the\r\nmailbox. You can delete the rule or form using the Outlook client or using Exchange PowerShell.\r\n1. Identify all devices where the user has used Outlook. They all need to be cleaned of potential malware.\r\nDon't allow the user to sign on and use email until all devices have been cleaned.\r\n2. On each device, follow the steps in Delete a rule.\r\n3. If you're unsure about the presence of other malware, you can format and reinstall all the software on the\r\ndevice. For mobile devices, you can follow the manufacturers steps to reset the device to the factory image.\r\n4. Install the most up-to-date versions of Outlook. Remember, current version of Outlook blocks both types of\r\nthis attack by default.\r\n5. Once all offline copies of the mailbox have been removed, do the following steps:\r\nReset the user's password using a high quality value (length and complexity).\r\nIf multi-factor authentication (MFA) isn't turned on for the user, follow the steps in Setup multi-factor authentication for users\r\nThese steps ensure that the user's credentials aren't exposed via other means (for example, phishing or\r\npassword reuse).\r\nConnect to the required Exchange PowerShell environment:\r\nMailboxes on on-premises Exchange servers: Connect to Exchange servers using remote PowerShell or\r\nOpen the Exchange Management Shell.\r\nMailboxes in Exchange Online: Connect to Exchange Online PowerShell.\r\nAfter you connect to the required Exchange PowerShell environment, you can take the following actions on Inbox\r\nrules in user mailboxes:\r\nhttps://docs.microsoft.com/en-us/office365/securitycompliance/detect-and-remediate-outlook-rules-forms-attack\r\nPage 4 of 7\n\nView Inbox rules in a mailbox:\r\nView a summary list of all rules\r\nGet-InboxRule -Mailbox laura@contoso.onmicrosoft.com\r\nView detailed information for a specific rule:\r\nGet-InboxRule -Mailbox laura@contoso.onmicrosoft.com -Identity \"Suspicious Rule Name\" | Format-Li\r\nFor detailed syntax and parameter information, see Get-InboxRule.\r\nRemove Inbox rules from a mailbox:\r\nRemove a specific rule:\r\nRemove-InboxRule -Mailbox laura@contoso.onmicrosoft.com -Identity \"Suspicious Rule Name\"\r\nRemove all rules:\r\nGet-InboxRule -Mailbox laura@contoso.onmicrosoft.com | Remove-InboxRule\r\nFor detailed syntax and parameter information, see Remove-InboxRule.\r\nTurn off an Inbox rule for further investigation:\r\nDisable-InboxRule -Mailbox laura@contoso.onmicrosoft.com -Identity \"Suspicious Rule Name\"\r\nFor detailed syntax and parameter information, see Disable-InboxRule.\r\nThe Rules and Forms exploits are only used by an attacker after they've stolen or breached a user's account. So,\r\nyour first step to preventing the use of these exploits against your organization is to aggressively protect user\r\naccounts. Some of the most common ways that accounts are breached are through phishing or password spray\r\nattacks.\r\nThe best way to protect user accounts (especially admin accounts) is to set up MFA for users. You should also:\r\nMonitor how user accounts are accessed and used. You may not prevent the initial breach, but you can\r\nshorten the duration and the effects of the breach by detecting it sooner. You can use these Office 365\r\nCloud App Security policies to monitor accounts and alert you to unusual activity:\r\nMultiple failed login attempts: Triggers an alert when users perform multiple failed sign in\r\nactivities in a single session with respect to the learned baseline, which could indicate an attempted\r\nbreach.\r\nhttps://docs.microsoft.com/en-us/office365/securitycompliance/detect-and-remediate-outlook-rules-forms-attack\r\nPage 5 of 7\n\nImpossible travel: Triggers an alert when activities are detected from the same user in different\r\nlocations within a time period that's shorter than the expected travel time between the two locations.\r\nThis activity could indicate that a different user is using the same credentials. Detecting this\r\nanomalous behavior necessitates an initial learning period of seven days to learn a new user's\r\nactivity pattern.\r\nUnusual impersonated activity (by user): Triggers an alert when users perform multiple\r\nimpersonated activities in a single session with respect to the baseline learned, which could indicate\r\nan attempted breach.\r\nUse a tool like Office 365 Secure Score to manage account security configurations and behaviors.\r\nFully updated and patched versions of Outlook 2013, and 2016 disable the \"Start Application\" rule/form action by\r\ndefault. Even if an attacker breaches the account, the rule and form actions are blocked. You can install the latest\r\nupdates and security patches by following the steps in Install Office updates.\r\nHere are the patch versions for Outlook 2013 and 2016 clients:\r\nOutlook 2016: 16.0.4534.1001 or greater.\r\nOutlook 2013: 15.0.4937.1000 or greater.\r\nFor more information on the individual security patches, see:\r\nOutlook 2016 Security Patch\r\nOutlook 2013 Security Patch\r\nEven with the patches and updates installed, it's possible for an attacker to change the local machine configuration\r\nto reenable the \"Start Application\" behavior. You can use Advanced Group Policy Management to monitor and\r\nenforce local machine policies on client devices.\r\nYou can see if \"Start Application\" has been re-enabled through an override in the registry by using the information\r\nin How to view the system registry by using 64-bit versions of Windows. Check these subkeys:\r\nOutlook 2016: HKEY_CURRENT_USER\\Software\\Microsoft\\Office\\16.0\\Outlook\\Security\\\r\nOutlook 2013: HKEY_CURRENT_USER\\Software\\Microsoft\\Office\\15.0\\Outlook\\Security\\\r\nLook for the key EnableUnsafeClientMailRules :\r\nIf the value is 1, the Outlook security patch has been overridden and the computer is vulnerable to the\r\nForm/Rules attack.\r\nIf the value is 0, the \"Start Application\" action is disabled.\r\nIf the registry key isn't present and the updated and patched version of Outlook is installed, then the system\r\nisn't vulnerable to these attacks.\r\nCustomers with on-premises Exchange installations should consider blocking older versions of Outlook that don't\r\nhave patches available. Details on this process can be found in the article Configure Outlook client blocking.\r\nhttps://docs.microsoft.com/en-us/office365/securitycompliance/detect-and-remediate-outlook-rules-forms-attack\r\nPage 6 of 7\n\nMalicious Outlook Rules by SilentBreak Security Post about Rules Vector provides a detailed review of\r\nhow the Outlook Rules.\r\nMAPI over HTTP and Mailrule Pwnage on the Sensepost blog about Mailrule Pwnage discusses a tool\r\ncalled Ruler that lets you exploit mailboxes through Outlook rules.\r\nOutlook forms and shells on the Sensepost blog about Forms Threat Vector.\r\nRuler Codebase\r\nRuler Indicators of Compromise\r\nSource: https://docs.microsoft.com/en-us/office365/securitycompliance/detect-and-remediate-outlook-rules-forms-attack\r\nhttps://docs.microsoft.com/en-us/office365/securitycompliance/detect-and-remediate-outlook-rules-forms-attack\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://docs.microsoft.com/en-us/office365/securitycompliance/detect-and-remediate-outlook-rules-forms-attack"
	],
	"report_names": [
		"detect-and-remediate-outlook-rules-forms-attack"
	],
	"threat_actors": [],
	"ts_created_at": 1775434778,
	"ts_updated_at": 1775826777,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/c71de28ecea948157d1f84e3bc8e38a944762f2e.pdf",
		"text": "https://archive.orkl.eu/c71de28ecea948157d1f84e3bc8e38a944762f2e.txt",
		"img": "https://archive.orkl.eu/c71de28ecea948157d1f84e3bc8e38a944762f2e.jpg"
	}
}