Blocking malicious activity – too many email updates

Using Microsoft’s Cloud App Security is an invaluable tool for an administrator. During presentations, I’ve noted that there are nearing 100 policies managing my tenant because organized crime has gotten really good at finding new way to infiltrate networks and they make themselves more difficult to detect than ever before. This rule isn’t a preventative measure. What it does is catch a malicious act in progress and puts a stop to it.

Excessive email updates

Typically, after an email has been sent, that email is not modified. It stays in it form for the rest of its lifecycle. The same is often true for read emails. But what if those emails were suddenly being modified in mass? This would likely be an indicator of malware that was not caught before it could act. We all want proactive blocking of malware but sometimes it’s not possible. We also have to have preventative measures in place to protect our data. Security is all about the layers.

This type of incursion into email theoretical. The encryption of email does happen. We need to build a monitoring policy that will stop this malicious activity.

Create a cloud app security policy

In Cloud App Security, create a new Threat Detection policy.

This will be a high severity policy. Provide a description in your own words, similar to the figure below.

This policy is unlikely to generate false positives, except in the case of legacy style anti-virus scanning. This policy has been in place since, September 2020, and has only generated 1 false positive.

Start a new Treat detection policy

In the Filters section of the policy, select Repeated activity and select the most restrictive timeframe that your environment will tolerate. Encryption happens quickly, so you want to catch this malicious activity as quickly as possible. It has been a long time since I’ve seen an encryption event (knocking wood) but when I did, thousands of files were encrypted a minute. Because of that it is unlikely that this policy will protect the data in an individual mailbox, but that’s OK, our point with this policy is to be alerted and shutdown an event that made it though our other layers of proactive protection.

Encryption happens quickly, so you want as short a timeframe as tolerable for detection

To create a policy like this, we had to simulate the event happening. For this we used a malware simulation tool. This then generated an activity log which we then used to configure the rule. In the activity log we saw that the activity to watch was activity ID LgAAAADEtTGDdZenT6dYVcG+zOStAQAxwuh4Dlj5RYMKKDqpnVSTAAAAAAERAAAB. This meant that we needed to configure our policy to detect Updates, in Exchange of that Activity.

In the figure before you can see what the rule looks like for the policy.

Create an activity policy that matches the activity log event

Our alerts are typically sent into our monitoring portal, which we designed in Microsoft Teams. However, due to the nature of this alert, we instead chose to send into the portal AND also send as an email directly to several people in our company. You could also have a text message sent if you choose to setup a Power Automate playbook.

In the figure below, we see that email messages will be sent to three mailboxes, one of which is the ticketing portal itself. These obviously won’t reach their destination if they are the infected mailbox but one of them probably will at least. Because of the risk of the message not being delivered, we have also chosen to run a power automate flow when this alert is triggered. This Power Automate flow will isolate the machine that triggered the alert from the network. This is a pre-configured template that is available from Power Automate and makes use of Defenders hunting capabilities. Be careful! It would not be difficult to isolate all machines.

You can learn more about configuring automation in this interactive guide. Automate alerts management with Microsoft Power Automate and Cloud App Security (

You can learn a little bit more about the power of machine isolation here:

Consider sending alerts to multiple locations

For the final component, we will suspend the user from the network that triggered the alert. This does require Defender for Cloud Apps licensing. The effect of the suspension is that the user is logged off and cannot log back in until the administrator clears the suspension.

User will be logged off of Micrsoft 365

I often get asked how we manage networks without an RMM tool and I always reply that we take full advantage and make use of what Microsoft has to offer. This type of rule is an example of that philosophy. If you want to learn more please read my posts on Azure AD, Defender and Intune.

All we do is support IT professionals. Microsoft 365 technical assistance, occasional Newsletter, Security community, MSP Legislation community, Intune, Defender and Lighthouse community, Peer groups, Papers, Business consulting and more. and for the community groups listed above.

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.