Along with being the inspiration for the name of our firm, in ecology, “crypsis” is the ability of an animal to avoid observation or detection by other animals. It may be a predation strategy or an antipredator adaptation. Methods include camouflage, nocturnality, subterranean lifestyle and mimicry (not to be confused with Mimikatz). In computer security, there is a similarly important ability for the elusive threat actor to avoid detection from the persistent incident responder. Let's explore a particularly challenging method of avoiding detection by a threat actor who has obtained access to a victim’s Microsoft 365 account.
Investigating a Business Email Compromise (BEC) requires access to email logs as a critical source of evidence to understand the story of the breach. These logs can help us answer these important questions: What did the threat actors see? What did the threat actors touch? What did they take? And how long did they spend doing it? However, just looking at the email logs is not enough, especially if the attacker has implemented rules, or worse yet, hidden rules.
Threat actors will often implement rules to exfiltrate emails. If these malicious rules are not found and removed, the threat actor can continue to access emails long after a victim changes their password. These rules can be found by querying various properties in the victim mailbox. However, in some cases, the threat actor will take a couple of additional steps to remove these properties, thereby hiding the ability to detect the malicious rules.
The first step in responding to this elusive persistence mechanism is understanding how to identify hidden rules. In this blog, I will show you how hidden rules are created, some tips about when you should suspect hidden rules are in place, and how you can find them.
Predators need to change their perspective when hunting the Hawaiian bobtail squid (Euprymna scolopes). This squid uses a form of crypsis to produce light to blend into surface reflections and evade predators from below. Let's change our perspective and see if we can detect an elusive threat actor.
Creating Hidden Rules
After successfully obtaining a victim user’s credentials (usually through phishing), the threat actor can create a hidden rule. The threat actor starts by creating a visible rule using either Microsoft’s mail client, Outlook, via the web or via the desktop/mobile client. Here, the threat actor has the ability to set the rule to perform an action such as deleting or forwarding emails based on a set of criteria, such as the existence of specific words in the email.
Using a legitimate third-party Microsoft tool for mailbox administration (MFCMAPI), the threat actor can modify the rule. First, the threat actor connects to the victim’s mailbox in MFCMAPI by syncing the mailbox with Outlook’s desktop mail client. Then, using cached credentials from the Outlook profile, a connection is established in MFCMAPI. Once the victim’s mailbox has loaded, the threat actor now has access to the mailbox’s “IPM_SUBTREE”—a container that holds the mailbox’s folders.
This part is key because that container holds the “Inbox” folder, which houses inbox rules. From here, their method is simple. First, they identify a rule based on the Message Class “IPM.Rule.Version2.Message.”
Once the desired rule has been identified, the threat actor deletes the values for the following two fields: “PR_RULE_MSG_NAME_W” and “PR_RULE_MSG_PROVIDER_W.”
The rule will now disappear on both the front end (Microsoft Outlook, and Office.com) and the back end (Microsoft’s 365 API), but remain active.
Uncovering Tips on Identification and Response
When does an incident responder begin to wonder if hidden rules are at play? Are there any signs they could be looking for? There are two scenarios that should alert incident responders:
- A user’s mailbox is deleting new emails.
- A user’s mailbox is forwarding new emails.
Why are these two scenarios important? In the first, a threat actor is hiding specific emails from the user. In the second, the threat actor is sending out copies of new inbound emails to their own email address. In a normal attack, an active visible rule will most likely be the culprit. However, if no rules can be found by traditional means, then you have a good candidate for hidden rules.
While sophisticated BEC attacks such as these are not common, they do indicate the presence of a formidable opponent. Manual investigations into hidden rules are not practical. First, they are unrealistically time consuming. Second (and most importantly), they require investigators to follow the steps of the threat actor. This includes using the victim’s credentials to sync their mailbox, possibly collecting a significant amount of PII and PHI, which may require approvals from legal counsel.
Even if you were to investigate manually and discover that a hidden rule is the reason behind emails being deleted and/or forwarded, it would be very difficult to remove them without doing a full flush of all rules in the mailbox. MFCMAPI is one way to help delete the rule, but is there a better way? Let’s explore.
Changing Perspective: Building Our Response
To circumvent the challenges above, I turned to open source research to understand the types of existing tools that allow investigators to respond to this threat. One tool I found, called Hawk, was written by the user Canthv0 to allow administrators to collect logs from Microsoft’s Office 365 and EWS APIs. One specific module in Hawk tries to identify hidden inbox rules by leveraging the API to search a user’s mailbox parameters without the need for MFCMAPI. The capabilities of a tool like this could allow investigators to identify hidden rules without the need to sync a user’s mailbox. Though Hawk’s hidden rule identification capability is useful, it comes with a limitation. I found that when a potential hidden rule is pulled back through the API, it is still unclear what the actions of the rule are and its impacts on the user. The action field is encoded, but decoding it reveals limited insight into what the rule does. Another important note about Hawk is that when starting the Hawk service, you have to accept the End-User License Agreement (EULA) that states it will collect information.
Hawk and other existing tools allow incident responders to identify the existence of a hidden rule, but do not include the capability to identify exactly what the hidden rule does to help incident responders remediate the concern.
Using existing tools as the base, I built a BEC response capability to identify, analyze, and make hidden mailbox rules visible. First, the script requests and queries mailbox rule data from the victim’s mailbox via Microsoft’s EWS API using an administrator account. The script can then automatically push values into the missing value locations to add a name to the rule and make it visible on both the front end and the back end. As discussed earlier, “PR_RULE_MSG_NAME_W” and “PR_RULE_MSG_PROVIDER_W” are the two fields that if the values are blank, will make the rule hidden. Thus, adding values back to these fields allows the rule to be visible again. This then allows traditional rule collection to pull back the rule. An analyst can then fully understand what the actions of the rule are and the extent of the damage. At this point, the rule can now be analyzed before it is removed.
This method may be rare today, but we suspect threat actors will continue to evolve, requiring incident responders to respond with new capabilities and perspectives. By sharing our knowledge of this clever method for avoiding detection and potential solutions, I hope that we can raise awareness and support other incident responders in similar attack investigations.
How to Protect Against This Attack:
- To help prevent unauthorized access of email accounts through credential-stealing phishing campaigns, implement Multi-Factor Authentication (MFA) as a security policy for all employees.
- To prevent threat actors from circumventing MFA, disable legacy authentications/protocols and confirm that MFA is not only deployed, but that employees are also using it correctly.
- Use anti-spoofing and email authentication techniques, like Sender Policy Framework (SPF).
- Require unique and complex passwords that are at least 15 characters in length so they cannot be easily brute forced.
- Implement blocking or alerting for auto-forwarding rules that forward messages externally.
- Create custom retention tags for email that: automatically move older items to archive; delete items older than a certain age (e.g., five years); and permanently delete items no longer needed (e.g., those older than seven years) from both primary and archive mailboxes. Keep in mind, however, that archival policies should align with compliance requirements.
- Consider blocking account logins based on geographic regions if not needed for normal business operations.
- Adopt advanced phishing protection/machine learning solutions like those offered through Microsoft 365 Advanced Threat Protection or other third-party solutions to detect and deter sophisticated phishing campaigns.