I recently met with a customer to discuss their migration from Kaspersky to Microsoft Defender ATP. They also use macmon to query the AV’s database to detect alerts and move affected clients to an isolated VLAN. Although MDATP is capable of handling incidents itself, the customer wanted to retain the capability to auto-isolate machines.
At first, we tried Custom Detection Rules that are now part of Advanced Hunting. Unfortunately, they only run once after creation plus every 24 hours after that without customization at the moment.
So, we had to switch to Microsoft Flow, and a whole new world of possibilities opened up. MDATP and Flow: better together.
Create a service account (and protect it)
First, we need a service account to create the connectors to MDATP and Exchange Online (for mail alerts) in Flow. So, it needs an appropriate role and a mail box. Make sure that the account has the appropriate licenses for Flow, email, and security features (Azure AD Premium P2, e.g.).
In this case I used the Azure AD role “security administrator”:
MDATP also supports a more fine-grained delegation model that can be found in the portal under settings > roles:
However, you would also have to link these MDATP roles to an Azure AD group. As often more people can edit those than you might like, I chose Azure AD’s security administrator.
We will not be able to secure the service account with MFA because it has to sign-in unattended. Therefor, it needs a strong password:
In this case, I just auto generated a 64 character password using KeePass. Azure AD now supports up to 255 characters, so you’re free to go even higher.
Next, make sure there are user risk and sign-in risk policies in Azure AD Identity Protection that target the service account. While we are not planning to use MFA on a frequent basis, Microsoft should still be able to protect the account if it is at a certain risk level. I’d recommend “medium and above”. Please also read the note below the next screenshot carefully!
Please note!It is imaginable that an attacker finds out the name of your service account and tries to DoS it by either signing in from various IP addresses or brute forcing it. These actions might trigger Identity Protection to increase the accounts risk level which would stop Flow from having access to MDATP. Eventually, this would also render every action you define in the workflow useless.
To mitigate this scenario set up all Identity Protection alerts to send emails in such a case.
Connect Flow to MDATP
As the service account is now ready, we can head over to Flow at https://flow.microsoft.com.
Once you have signed with the service account select Connectors on the left panel. There you can search for Defender ATP.
Please noteThe Defender ATP connector for Microsoft Flow is a premium connector that has different licensing prerequisites. I will not go into detail about that in this post.
Next, click the connector and select “Triggers” as shown here:
Next, sign-in to MDATP to establish the connection:
The first workflow
The trigger is ready:
The connection is now functional, and you can start creating your workflow by clicking “New step”.
First, you should always start by gathering required information. In this case, all we need are MDATP alert and machine parameters. I also added a condition that lets me filter for different alert severities:
If “Alert Alert severity” matches “High” or “Medium” the condition is set to “true” switching to the “If yes” side on the left.
This is where machine actions and mailing will be processed. For each machine action you have to define “Machine Machine ID” as the “Machine ID” for an action. This is a bit confusing at first. But please keep in mind that we are not accessing all machine IDs, but only those that are linked to an alert we selected in the condition above.
In this case, I put two actions in place: “Isolate machine” and “Restrict app execution”.
Using the “Send an email (V2)” action you can link the mailbox of the service account to Flow which will then send notifications to another address of your choice. You can use all kinds of parameters from the connector to put useful information into it. Computer names, time stamps, and descriptions could be one of the obvious choices.
On the endpoint, network connections will now be blocked …
…and app execution will be restricted:
(No disrespect to Chrome or Google, it was just the first non-Microsoft app that came to my mind 🙂 )
Other interesting examples
Of course, this scenario was very simple. There are many other use cases you could cover with Microsoft Flow, e.g.:
- Use Microsoft Cloud App Security as a trigger instead of Defender ATP
- Implement approvals for automatic action, there is built-in module for that: “Start and wait for an approval”
- Trigger antivirus scans
- Collect an investigation package
- Run a custom Advanced Hunting query and use the output for other actions
- Create a new alert
- Automatically collect Advanced Hunting data, e.g. in order to monitor your Application Control or USB device policies
- Allow users to remove isolation and app restrictions via mail after MDATP cleaned up the device successfully.
- Export relevant data to an external file or system (MDATP only retains data for 180 days maximum)
- Or do whatever you like in the tenant by connecting Graph API.
I hope I could give you a first impression about the vast capabilities of Microsoft Flow. However, please always follow best practices to secure all accounts you use for Flow connectors. They often are highly privileged and could be abused to damage or delete all kinds of entities.
Thanks for reading!