{
	"id": "da9f6d15-399b-4856-925c-2dbfd7d37085",
	"created_at": "2026-04-06T03:36:30.713789Z",
	"updated_at": "2026-04-10T03:20:06.369963Z",
	"deleted_at": null,
	"sha1_hash": "093776c91c0391a99a9fe3717bb281d09772e0c8",
	"title": "Defending Against Rules and Forms Injection",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2445318,
	"plain_text": "Defending Against Rules and Forms Injection\r\nBy kexugit\r\nArchived: 2026-04-06 03:15:49 UTC\r\nOver the last year, Office 365 security has been tracking an emergent attacker persistence mechanism in the\r\nExchange Online ecosystem. The release of a security research tool called Ruler enables an attacker to install a\r\npersistence mechanism once an account has been breached to maintain access even through a password roll. While\r\nwe haven't seen widespread use of the tool in Office 365, we wanted to equip IT Security Administrators with a\r\nrobust understanding of the threat, a model for how to prevent the exploit, and some lightweight tooling to detect,\r\nmonitor, and remediate the threat. The good news here is that if you keep your clients patched to the latest version,\r\nyou are not vulnerable to the threat as Outlook client defaults block both mechanisms. You should still perform the\r\nactions in the 'How to Detect It' section, however, in case an account was breached prior to the patch releases last\r\nyear.\r\nThe Threat\r\nThere are two variants of the persistence mechanism: mailbox rules and custom mail forms. In both cases, the\r\nrule/form is synced from the cloud service down to the desktop client, so a full format and re-install of the client\r\nsoftware doesn't eliminate the injection mechanism as resyncing the mailbox will re-download the rules/forms\r\nfrom the cloud. The rules/forms, once placed, are used to execute remote or custom code, usually to install\r\nmalware on the local machine, which is in turn leveraged to re-steal credentials or perform other illicit activity.\r\nYou can read an in-depth description of the exploits here:\r\nSilentBreak Security Post about Rules Vector: https://silentbreaksecurity.com/malicious-outlook-rules/\r\nSensepost Blog about Mailrule Pwnage: https://sensepost.com/blog/2016/mapi-over-http-and-mailrule-pwnage/\r\nSensepost Blog about Forms Threat Vector: https://sensepost.com/blog/2017/outlook-forms-and-shells/\r\nRuler Codebase: https://github.com/sensepost/ruler\r\nThe exploits exhibit the following characteristics:\r\n1. A user's credential is compromised and an attacker logs on to their Exchange account (Exchange Online, or\r\nOn-Premise)\r\n2. The attacker creates a forwarding rule in the target's mailbox...\r\n3. That when triggered with an email that matches the rule criteria...\r\n4. Will execute an application...\r\n5. Usually hosted on a remote WebDav server...\r\n6. That installs malware locally such as Powershell Empire\r\n7. Which allows attacker to dump creds from local machine and perform other malicious activities\r\nThis is what the exploit looks like:\r\nhttps://blogs.technet.microsoft.com/office365security/defending-against-rules-and-forms-injection/\r\nPage 1 of 9\n\n1. A user's credential is compromised and an attacker logs on to their Exchange account (Exchange Online, or\r\nOn-Premise)\r\n2. The attacker creates a custom mail form template and injects it into the target's mailbox...\r\n3. That when triggered with an email that matches the custom form template type...\r\n4. Will execute custom code in the template...\r\n5. That usually installs malware locally such as Powershell Empire\r\n6. Which allows attacker to dump creds from local machine and perform other malicious activities\r\nThis is what the exploit looks like:\r\nHow to Prevent It\r\nhttps://blogs.technet.microsoft.com/office365security/defending-against-rules-and-forms-injection/\r\nPage 2 of 9\n\nThe Ruler exploit described here is considered a post-exploit technique, which means the account has already\r\nbeen breached by the attacker when this exploit is executed. Taking aggressive steps to prevent the initial breach\r\nin the first place is advised. There are many account breach vectors, including phishing and password spraying,\r\nwhich are relatively easy to execute. Using protection mechanisms like multi-factor authentication on user\r\naccounts, whether conditional or always-on, is an effective mitigation. This should be your first line of defense.\r\nSome effective tactics you can leverage include:\r\n1. Enable Multi-factor Authentication for all of your users, especially those with administrative privileges.\r\n2. Monitor your accounts for illicit activity. You can do this manually, or with a security monitoring toolset.\r\nThis may not prevent the initial breach, but will shorten the duration, and the impact of the breach.\r\n3. Leverage a tool like the Office 365 Secure Score (https://securescore.office.com) to manage account\r\nsecurity configurations and behaviors.\r\nThe second key prevention mechanism is to use the fully-updated latest versions of Outlook (2013/2016) and\r\nensuring that rule actions that can start applications/macros are disabled per the security patches. This will ensure\r\nthat, even if an attacker breaches the account, the rule and form execution mechanisms will be blocked.\r\nPatched versions are 15.0.4937.1000 or greater (Outlook 2013) and 16.0.4534.1001 or greater (Outlook\r\n2016).  Details about the patches are here:\r\nOutlook 2013 Security Patch - https://support.microsoft.com/en-us/help/3191938\r\nOutlook 2016 Security Patch - https://support.microsoft.com/en-us/help/3191883\r\nCustomers with on-premises Exchange installations should consider blocking older versions of Outlook that do\r\nnot have patches available. Details on this process can be found in the article “Configure Outlook client blocking”.\r\nPlease note that the rule mitigation is to disable the \"Start Application\" rule action by default. Even with the patch,\r\nit is possible for an attacker to change the local machine configuration to re-enable this. Make sure you monitor\r\nand enforce local machine policies on your clients. If you do happen to have an important business process that\r\nrelies on this functionality, you can enable it for your users, but you will need to monitor your deployed user roles\r\nas per below with extra vigilance.\r\nTo determine if “Start application” is enabled via override in the registry, check for 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\nIf the key EnableUnsafeClientMailRules exists with a value of 1, the patch is overridden and allows the action\r\nabove.  If the value is 0, the rule actions are disabled.  If a current (fixed) version of Outlook is installed and this\r\nregistry key is NOT present or present and set to 0, then a system is not susceptible to the mail rule injection\r\nexploit.\r\nThe custom mail form injection exploit relies on custom code being injected into a very rarely used custom mail\r\nform feature and then executed outside the normal office macro sandbox. New versions of Outlook client prevent\r\nthis code execution.\r\nhttps://blogs.technet.microsoft.com/office365security/defending-against-rules-and-forms-injection/\r\nPage 3 of 9\n\nHow to Detect It\r\nThere are several methods you can leverage to detect and monitor for this exploit in your organization.\r\nUsing Powershell\r\nThe simplest method is to leverage a Powershell script we have created which allows you to dump all of the mail\r\nforwarding rules and custom forms for all the users in your tenancy: https://github.com/OfficeDev/O365-\r\nInvestigationTooling/blob/master/Get-AllTenantRulesAndForms.ps1 . You will need to have a global admin role\r\nelevation to run the script (because it connects to every mailbox in the tenancy to read the rules and forms). It\r\ntakes no parameters. The script is written for an Office 365 organization, so if you are using Exchange on-prem,\r\nyou'll need to modify it. The script will produce two time-stamped CSV files: one for rules and one for forms. The\r\nrules one should be examined for action conditions that include applications or executables. Two columns in the\r\nMailboxRulesExport_DATE.csv file will help focus your search.\r\nThis assesses the rule to see if there is a custom action, if the action is to execute an application, or if the\r\naction is run a macro. Any of these conditions will flag the rule as being potentially malicious.\r\nThis field contains the actual execution string if the rule executes an action. If it calls a remote server, or a\r\nsuspiciously named application, it is likely malicious.\r\nUsing Security Researcher Toolkit\r\nAnother method you can leverage is to use the defensive version of the Ruler toolkit called NotRuler, authored by\r\nthe same researcher: https://github.com/sensepost/notruler. The author has helpfully included a list of IOCs for the\r\nRuler toolkit: https://github.com/sensepost/notruler/blob/master/iocs.md.\r\nUsing Outlook or MFCMAPI\r\nIf you are willing to do substantial spelunking one mailbox at a time, you can also leverage the Outlook client or\r\naccess the mailbox database directly by using the MFCMAPI tool. While this is time consuming and can result in\r\na breach of the machine you are using to investigate the suspected breached mailbox, it is the most straightforward\r\nand complete enumeration of the exploit in context. Use the rule management interface form outlook and examine\r\neach rule description:\r\nhttps://blogs.technet.microsoft.com/office365security/defending-against-rules-and-forms-injection/\r\nPage 4 of 9\n\nOr, enable the developer tab in the Outlook client, click design a form, and look in the user's Inbox for custom\r\nforms. The Ruler tool will, by default, mark the custom form as hidden. Once you open the form, click \"View\r\nCode\" to see what the custom form actually runs:\r\nhttps://blogs.technet.microsoft.com/office365security/defending-against-rules-and-forms-injection/\r\nPage 5 of 9\n\nYou can also MFCMAPI to connect to the suspected breached mailbox, find the Inbox Folder, right click and open\r\nassociated contents table, the look for Message Class IPM.Rule.Version2.Message (for malicious rules) and\r\nIPM.Microsoft.FolderDesign.FormsDescription (for malicious forms). Custom forms are rare enough that if you\r\nhave any custom forms, it is worth a deeper look.\r\nhttps://blogs.technet.microsoft.com/office365security/defending-against-rules-and-forms-injection/\r\nPage 6 of 9\n\nBroadly speaking, you are looking for the following indicators of compromise:\r\nIndicators of compromise for rules\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 compromise for forms\r\nCustom form present saved as their own message class\r\nMessage class contains executable code\r\nUsually stored in Personal Forms Library or Inbox folders\r\nForm is named IPM.Note.[custom name]\r\nIf you discover that you have been compromised with this vector, remediation of the actual exploit is\r\nstraightforward: delete the rule or form from the mailbox. You can do this with the Outlook client, MFCMapi, or\r\nusing remote PowerShell to remove rules. A full remediation, however, is more in depth and looks like:\r\n1. Remove the rule or form from the user's mailbox using Outlook, remote Powershell, or MFCMapi.\r\n2. Do not allow the user to logon and use email until the full remediation process is complete.\r\n3. Every machine that the user has used with Outlook will need to be cleaned of potential malware. The\r\nsimplest way to accomplish this is to format and re-install everything on the machine, but if you can ensure\r\nthat all malware has been removed with high confidence that might work.\r\n4. Ensure that you install the most up-to-date versions of Outlook so that the vector is closed.\r\n5. Once all offline copies of the mailbox have been removed, reset the user's password (ensuring it has a high-quality one set) and enable multi-factor authentication on the account to ensure the user's credentials are\r\nnot exposed via other means (such as phishing or password re-use).\r\nhttps://blogs.technet.microsoft.com/office365security/defending-against-rules-and-forms-injection/\r\nPage 7 of 9\n\nDeleting with Outlook\r\nDeleting with MFCMapi\r\nThere are two remote powershell cmdlets you can use to remove or disable dangerous rules:\r\nRemove-InboxRule: https://technet.microsoft.com/en-us/library/dd351272(v=exchg.160).aspx\r\nhttps://blogs.technet.microsoft.com/office365security/defending-against-rules-and-forms-injection/\r\nPage 8 of 9\n\nDisable-InboxRule: https://technet.microsoft.com/en-us/library/dd298120(v=exchg.160).aspx (use if you\r\nneed to retain the rule contents for further investigation)\r\nRuler Codebase: https://github.com/sensepost/ruler\r\nSilentBreak Security Post about Rules Vector: https://silentbreaksecurity.com/malicious-outlook-rules/\r\nSensepost Blog about Mailrule Pwnage: https://sensepost.com/blog/2016/mapi-over-http-and-mailrule-pwnage/\r\nSensepost Blog about Forms Threat Vector: https://sensepost.com/blog/2017/outlook-forms-and-shells/\r\nGet-AllTenantRulesAndForms.ps1: https://github.com/OfficeDev/O365-InvestigationTooling/blob/master/Get-AllTenantRulesAndForms.ps1\r\nMFCMAPI: https://github.com/stephenegriffin/mfcmapi\r\nOutlook 2013 Security Patch - https://support.microsoft.com/en-us/help/3191938\r\nOutlook 2016 Security Patch - https://support.microsoft.com/en-us/help/3191883\r\nSource: https://blogs.technet.microsoft.com/office365security/defending-against-rules-and-forms-injection/\r\nhttps://blogs.technet.microsoft.com/office365security/defending-against-rules-and-forms-injection/\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://blogs.technet.microsoft.com/office365security/defending-against-rules-and-forms-injection/"
	],
	"report_names": [
		"defending-against-rules-and-forms-injection"
	],
	"threat_actors": [],
	"ts_created_at": 1775446590,
	"ts_updated_at": 1775791206,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/093776c91c0391a99a9fe3717bb281d09772e0c8.pdf",
		"text": "https://archive.orkl.eu/093776c91c0391a99a9fe3717bb281d09772e0c8.txt",
		"img": "https://archive.orkl.eu/093776c91c0391a99a9fe3717bb281d09772e0c8.jpg"
	}
}