Executive Summary
In a recent LevelBlue incident response engagement, an analyst in our managed detection and response (MDR) security operations center (SOC) responded to an alarm that was triggered by a suspicious email/inbox rule. The rule aimed to conceal responses to an internal phishing attempt from the account user, so the attacker could solicit funds from the company's users. According to a report by the Cybersecurity and Infrastructure Security Agency (CISA), “Email systems are the preferred attack vector for malicious phishing campaigns. Recent reporting shows 32 percent of breaches involve phishing attacks.”
During the triage of the alarm, the analyst analyzed various artifacts and event logs to understand the extent of the compromise. They examined email logs and account activity to identify the initial point of entry and the methods used by the attacker. Their rapid detection of the suspicious rule and subsequent analysis of the user activity logs was crucial in uncovering the attacker’s strategy and preventing further damage.
Introduction
In this incident, the attacker used an email rule to hide responses to an internal phishing email, ensuring that the compromised user would remain unaware of the ongoing malicious activity. This approach aligns with tactics seen in the MITRE ATT&CK framework, where attackers use email rules to hide evidence of their activities and maintain persistence (T1564.008). This allows them to maintain control over compromised accounts for longer periods, increasing the potential for data exfiltration and other malicious actions.
Investigation
The Alarm
The SOC analyst received an alarm from a Microsoft Exchange data source indicating that a suspicious inbox rule had been created. They examined the event that activated the alarm and quickly discerned from the rule parameters that this was case of business email compromise (BEC).
Figure 1: Alarm for suspicious inbox rule
Below, you can see the email parameters included within the newly created inbox rule, which was later identified to be created by the malicious actor who compromised the user’s account.
Figure 2: Snippet of the raw log showing the created rule parameters
Each parameter’s function is as follows:
- AlwaysDeleteOutlookRulesBlob: False – Indicates that the rule blob (a data structure used to store rules) is not set to be deleted automatically, allowing the rule to remain active and persistent
- Force: False – Suggests that the rule was not forcibly applied, which might imply that the attacker wanted to avoid drawing attention by making the change appear more natural.
- MoveToFolder: RSS Subscriptions – The rule is configured to move emails that match specific criteria to the “RSS Subscriptions” folder. This is a common tactic used by attackers to hide emails in less frequently checked folders, making it less likely for the user to notice suspicious activity.
- Name: “.” – The rule is given a minimal name (a single dot), likely to avoid drawing attention and blending in with other potential default or system-generated rules.
- SubjectContainsWords: “Capital Call Payment” – Specifies that the rule will apply to emails with the subject containing the phrase “Capital Call Payment”
- MarkAsRead: True – By marking the emails sent to the RSS folder as read, the attacker ensures that the email does not stand out as an unread message in the inbox, further reducing the likelihood of detection by the user.
- StopProcessingRules: True – Ensures that no other rules are processed after this one is applied. This is a critical setting as it ensures that this rule takes precedence and that its actions are not overridden or bypassed by subsequent rules.
More in-depth descriptions of these parameters and others can be found here.
Figure 3: Screenshot of the actual rule created by the attacker in the user’s inbox
Event Deep-Dive
Once the analyst established that the purpose of the rule was to move emails with the subject “Capital Call Payment” to the user’s RSS Subscriptions folder, they examined all email activity associated with this subject. It is not uncommon for an attacker to attempt to start an internal phishing campaign to elicit funds from internal users. By hiding specific emails in a less frequently checked folder (such as the RSS Subscriptions folder), an attacker can avoid immediate detection and potentially manipulate internal communications to achieve their malicious objectives.
The analyst reviewed the logs for the user with regard to the new inbox rule creation event and discovered an “Email Send” event that had occurred two minutes before the rule was created. This event shows the attacker sending an email with the subject “Capital Call Payment,” which indicates that not only did they create the rule to hide incoming responses, but they also used the compromised account to initiate an internal phishing campaign.
Figure 4: Log snippet showing sent email from the user with subject of “Capital Call Payment”
We can see from this “Email Send” event that the attacker is utilizing the web version of Outlook. When hackers are inside a compromised user’s inbox and utilizing email rules, they can take advantage of the fact that rules created in one version of Outlook (e.g., the web version) do not automatically synchronize with other versions (e.g., the desktop version). By creating a new inbox rule that remains invisible even if the user checks their Outlook application, the attacker can continue their actions unnoticed.
Figure 5: Log snippet showing the attacker utilizing Outlook on the web to send the “Capital Call Payment” email
After the “Capital Call Payment” email was sent out from the compromised user’s inbox, the analyst extensively searched the customer’s environment to see if any users had replied to the internal phishing email, and they discovered that one user had done so. The customer promptly advised the user that this was in fact a phishing email and prevented them from interacting with it further.
Figure 6: Sequence of events in attack
Customer Interaction
After the analyst had made their initial findings, they shared them with the customer. They identified the initial phishing email that the user had interacted with, which they suspected was the attacker's entry point. By tracing the attacker’s activities through the unique session ID linked to the user during the initial rule creation event, the analyst was able to provide valuable information to the customer. This included identifying whether users had responded to the internal phishing email and detailing all activities conducted by the attacker.
The customer took remedial actions on the account, such as revoking the user’s active sessions and resetting their password. Subsequent events indicate that the attacker was unable to gain further access to the account after these remediations.
Figure 7: "UserLoginFailed" event showing attacker no longer has access to the user’s account
This case highlights the sophistication of modern cyberattacks and the importance of vigilant monitoring, swift response, and robust security measures. By creating inbox rules to hide email responses to a targeted phishing email, the attacker aimed to elicit funds from internal users without raising immediate suspicion. However, the analyst’s prompt detection of the suspicious rule and subsequent analysis of the user activity logs uncovered the attacker’s strategy before they could inflict significant damage.
Organizations must be proactive in securing their email environments to protect against increasingly advanced cyber threats. The following best practices are recommended to protect against similar threats:
- Ensure that all user accounts have multi-factor authentication (MFA) enabled to add an extra layer of security.
- Implement tools and processes to conduct regular audits of new email rules for users to identify suspicious activity.
- Provide ongoing cybersecurity training to help employees recognize phishing attempts in order to prevent account compromises.
- Enable tools for employees to report on suspected phishing emails.