Microsoft 365 – Security Monitoring

Disclaimer: This is a very high-level post of M365 security monitoring leaving the technical stuff on the later blog posts. It doesn’t cover all products and possible integrations in the Microsoft cloud ecosystem and is more of a starting point for a journey of evaluating possible security solutions.

Security monitoring is a topic I have been working with my colleagues (@santasalojh & @pitkarantaM) for the last two years. During that time we have helped many organizations to get better visibility to cloud security monitoring. Now it’s time to share thoughts around this topic, starting from the root and digging deep down into the tech side.

Setting Up The Scene

Logging and monitoring is a huge topic in the Microsoft cloud ecosystem and for that reason, I will concentrate in this post to M365 security monitoring and alerts (which is quite obvious as a cyber-security expert), not the metrics in here. Also, I would like to highlight again that this blog is a very high level leaving the technical stuff on the later blog posts.

The questions I have heard quite often from customers are

  • Which native Microsoft tools I should use for monitoring the security of the cloud environment?
  • How can/should I manage all the alerts in the ecosystem (easily)?
  • Should I use 3rd party tools for security monitoring?

Unfortunately, I have to say that it depends on many things. It’s a matter of licenses, which tools you have on your toolbox, how much the organization is utilizing Microsoft cloud workloads, the maturity of the organization or service provider, other cloud service provider tools in use etc, …

Microsoft offers a brilliant set of cloud security solutions for use, here are a few named ones:

  • Azure Security Center
  • Microsoft 365 Security Center
  • Azure AD Identity Protection
  • Microsoft Defender ATP
  • Azure ATP & O365 ATP
  • Cloud App Security
  • Azure Sentinel

Architecture

Microsoft cyber-security architecture is the document for the start when the organization is planning cyber-security architecture in the Microsoft environment. In the first view, it looks a bit crowded, but once you get familiar with it, it will be beneficial. What’s covered here is the components inside the yellow circle, the Security Operations Center (SOC) part.

Internal Cloud Integrations

When planning security monitoring in the Microsoft cloud, the integrations (+ licenses) plays an important role to get most out of the security solutions. Some of the integrations are already in place by default but most of them need to be established by admin.

Integration Architecture – Example

The picture below doesn’t cover all possible security solutions and integration scenarios, it rather gives overall understanding which solutions can be used to investigate alerts and suspicious activity in the cloud or on-premises.

The best synergy advantages come with the integrations between security solutions. In the top category are the solutions which, in my opinion, are the best ones to start the investigation.

Naturally, if Sentinel is in use it triggers the alert and investigation starts from there. It could also be replaced by 3rd party SIEM (Splunk, QRadar, etc). Both Sentinel and Cloud App Security have a rich set of capabilities for investigation and contain a number of data from the user identity, device identity, and network traffic.

If you are wondering why investigation doesn’t start from Azure Security Center or M365 Security Center, the reason is that alerts from these solutions can be found or send to SIEM (in this example case – Sentinel).

Investigating The Alerts

Highly encourage to use SIEM (Sentinel) or MCAS for starting the investigation. Deep dive analysis can be made in the alert source itself, for example in MDATP if the initial alert was generated in there.

Azure Sentinel

Sentinel is a fully cloud-based SIEM solution and it offers also SOAR capabilities. Sentinel provides a single pane of glass solution for alert detection, threat visibility, proactive hunting, and threat response including Azure Workbooks & Jupyter Notebooks which can be used in advanced threat hunting and investigation scenarios.

Cloud App Security

Microsoft Cloud App Security (MCAS) is a Cloud Access Security Broker that supports various deployment modes including log collection, API connectors, and reverse proxy. MCAS has UEBA capabilities and as I have said many times it’s, in my opinion, the best tool in Microsoft ecosystem to investigate internal user suspicious, and possible malicious activity.

Intelligent Security Graph (ISG)

According to Microsoft: to be successful with threat intelligence, you must have a large diverse set of data and you have to apply it to your processes and tools.

The data sources include specialized security sources, insights from dark markets (criminal forums), and learning from incident response engagements. Key takeaways from the slide:

  • Products send data to graph
  • Products use Interflow APIs to access results
  • Products generate data which feeds back into the graph

In later blog posts, I will dig more deeply into the Security Graph functionalities. At the time of writing, the following solutions are providers to the ISG (GET & PATCH):

  • Azure Security Center (ASC)
  • Azure AD Identity Protection (IPC)
  • Microsoft Cloud App Security
  • Microsoft Defender ATP (MDATP)
  • Azure ATP (AATP)
  • Office 365
  • Azure Information Protection
  • Azure Sentinel

Integration with ISG makes sense if you are using on-prem SIEM and you don’t want to pull all of the logging and monitoring data from cloud to on-premises. Also, ISG contains processed alerts from the providers.

Note: During tests, I was not able to update alerts across security products even Microsoft documents says that it’s supported. I will address this topic in a later post which is still under investigation.

Conclusion

The best synergy advantages from the security solutions come with the integrations between the products. Even though, your organization would use 3rd party SIEM the internal cloud integrations between the solutions are very beneficial.

Integrations between cloud and SIEM systems are one of the topics covered later on in technical posts.

Until next time!

Defender ATP and Live Response

I wrote a post earlier about the integration between Microsoft Defender ATP (MDATP), Intune and conditional access. In that post I mentioned some of the investigation capabilities within MDATP, but left one key feature unexplored. So I wanted to dedicate one short post solely on that feature – Live Response.

Live Response is a fairly new feature allowing real-time access to clients managed by MDATP. The feature is not enabled by default, so you’ll have to enable it in the advanced features blade (note, that your clients must also be running Windows 10 version 18323 or later). There is a separate setting also for allowing unsigned scripts to be executed via the console (this relates to the PowerShell script execution capability explored later in the post).

Once you’ve enabled the feature, you can see the Initiate Live Response Session option on the machine page:

Selecting the option launches a command line interface on the browser:

Note, that this console is not a normal Windows command prompt, but you’ll only have a limited number of commands available. You can find the full list of available commands here. There are a number of useful commands to inspect running processes, network connections, registry, etc. You can also inspect files and perform static analysis (in this case, the malicious Word document used in the previous blog post came out clean):

One useful command is getfile which allows you to download individual files from the remote client. If you have an analysis machine with proper tools in place, you can continue investigations there. You can also quarantine the file on the remote client by running remediate.

The quarantine event is logged in the Windows event log of the client:

Gimme PowerShell!

While the set of out-of-the-box commands provided by the Live Response console does provide a useful tool set, it clearly has its limitations. Luckily, it also supports running custom PowerShell scripts on the remote client. Now, this is not an interactive PowerShell session, so it may sound a bit cumbersome. But it does work surprisingly well.

For my testing, I’m just running a couple of commands, but I want it to run for some time so that I can have a look at the process itself.

What I need to do first is to upload the file to the library. I also have the option to add parameters to the script.

I can verify that the file has been added to the library by running library on the console. The same command also allows to remove files from the library.

To run the script, I use the run command:

After a minute or so, I can see the PowerShell process in Process Explorer, and it’s running as a child-process of SenseIR.exe (under local system account).

Once the script execution is finished, the output is printed on the console. It will also pipe the output into a file that you can easily download to your local machine using the getfile command (the output file also contains information about the PowerShell version, the process ID used, etc.).

All the commands executed via Live Response are retained in the command log. This keeps a nice audit trail of the activities performed (although, the commands within the PS scripts are not shown, just the name of the script and the output file):

Summary

This was a quick introduction to the MDATP Live Response feature. Overall, this is a necessary addition to the toolkit. While the commands available at the interactive console is fairly limited, it seems to tackle the most critical use cases. And with the ability to download files and run PS scripts, this can be a powerful tool for the incident response teams.

LAB: Microsoft Defender ATP and Conditional Access

The integration between Intune and Microsoft Defender Advanced Threat Protection (MDATP) has been there for a while now. It’s an interesting feature, as it allows the risk score assigned by MDATP to be utilized in CA policies. Most organizations I’ve worked with only use Intune for MDM and MAM and still use SCCM (or the like) for managing workstations. While Intune’s capabilities in workstation management are still limited, it’s constantly evolving – and with SCCM co-management supported, it’s becoming a very viable option to enroll also your workstations into Intune. In any case, I wanted to do a quick experiment on how the MDATP -> Intune -> CA integration works, and how quickly we can go from detecting an alert in MDATP into actually making access restrictions in Azure AD based on the incident.

In all its simplicity, the environment is depicted in the picture below. The laptop in this case is just a VM running in Azure but it will do the trick. The Windows 10 is directly joined to Azure AD (this would work equally well with hybrid scenarios, but I got lazy setting up the local infrastructure). The device will be enrolled into Intune and into MDATP (using Intune).

Setup: Intune + MDATP + CA

To begin with, you have to integrate Intune with MDATP. You’ll find the setting within the Intune management blade:

As well as in the advanced settings of the MDATP portal:

Once the tenant level integration is done, you need to create a device configuration profile for MDATP:

The next thing you need is a device compliance policy. This will determine at which MDATP risk level the device will be marked as non-compliant. In my case, I’ve set it to ”Low”, which means that any risk level higher than that will push the device out of compliance. We’ll see how the risk levels are shown in MDATP later.

On the compliance policy settings we want to make sure that devices with no compliancy status will be marked non-compliant:

And finally, you should set up a security baseline for MDATP. Although not strictly required for this experiment, it gives you a good idea which MDATP features you can centrally manage via Intune. If you’re running your Windows 10 remotely, be careful with the firewall configurations. The default settings in the baseline will make you lose RDP connectivity (been there…).

Finally, we’ll create a couple of conditional access policies. For testing purposes, I’ll create two policies:

  1. Access to SharePoint Online will require either a compliant device or MFA
  2. Access to Exchange Online will require both a compliant device and MFA (picture below)

Enroll!

Now we’re good to go! I start by joining the Windows 10 client to Azure AD, which will also automatically enroll it into Intune (as I have enabled the enrollment policy). After that, I’ll login with an Azure AD account and run the following command. This should generate an informational alert in MDATP, just to show that we’re getting the data.

The information in the MDATP portal lags a few minutes behind, you have to wait for a bit for the information to appear. But eventually, you should see this:

As you can see, the risk level is currently ”No known risks”, as this activity is not considered suspicious. Note, this view also shows the machines exposure level. MDATP assesses any vulnerabilities on the host, either due to missing security patches or known vulnerable configurations. The exposure level does not impact the devices compliance status, but provides very useful information about the security posture of the device.

At this point, we can see our device also in Intune, and it is compliant with all the defined policies:

When I access SharePoint Online, I’m able to get in with just username and password. And if I login to Exchange Online, I need to authenticate using MFA, but I’m able to get in. So everything is working as expected. Note: if you’re using Chrome, you need to have the Windows 10 Accounts extension enabled. Otherwise the device information will not get conveyed to Azure AD, and it will assume that you’re using a non-compliant device.

Infect me!

Now, let’s break things. In order to do that, I need to simulate an attack on my Windows 10 device so that MDATP will increase the risk level. For that purpose I’m using a Word document that is crafted for this purpose.

The document contains a macro that drops two files on the desktop (diy_rs3_jscript_executes_ps.js and WinATP-Intro-Backdoorexe.jpg). It will then establish persistence by modifying the HKCU\Software\Microsoft\Windows\CurrentVersion\Run registry key. And finally, it starts a trusted process (RuntimeBroker.exe) and injects malicious code into it. This kind of pattern might go unnoticed from traditional anti-malware solutions, and that’s of course the point here.

Once I’ve opened the document, I’ll wait a couple of minutes and voilà! There’s not just one alert, but a bunch of them, and the device risk level jumped to High. We’ll briefly look into the forensics later, now we just want to see what happens with conditional access.

The information has also propagated to Intune via the integration and the device is no longer compliant (this took literally just a couple of minutes from the simulated infection):

At this point, I’m still able to use my open browser session as the access token is still valid (1 hour validity time). But I’m impatient so I just close my browser and reopen it. When I login to Exchange Online now, I get the following notice. In this case, it should say: ”Oops – you really shouldn’t have opened that document”.

I’m still able to access SharePoint Online but it now requires MFA. So the CA policies work just as expected.

Off the grid

One useful feature within MDATP is that you can completely isolate the client from the network. It might be that the device is currently in the corporate network, and therefore just restricting access through Azure AD might not be enough (unless you’ve implemented a full-blown zero-trust model).

Once I do that, it takes a minute or two and I lose my RDP connection. Luckily, that the device will still be able to communicate back to MDATP (well, it would be a pretty crappy feature otherwise). This way, once the remediation activities have been completed and, you can remotely allow the device back into the network. Also, I can still continue my forensic analysis while the device is safely off the grid.

CSI

So what would happen next? Obviously, at this point someone from the SOC team, or whoever is monitoring the alerts, would need to investigate what happend, and help getting the device back into compliance. There are a couple of MDATP features worth exploring at this point (we won’t go through everything). MDATP shows you the process tree during the incident, which gives a nice overview of what happened:

 You can also check on individual files, and where they have been seen in the organization, in this case I’m looking at the WinATP-Intro-Backdoorexe.jpg:

You can also take the file hash and use it to drill down to the data using the advanced hunting functionality. This allows you to search the data directly from the MDATP logs using Kusto query language (same that is used with Log Analytics). There’s also a community that has produced useful examples, both for generic use as well as for identifying specific exploits (https://github.com/microsoft/WindowsDefenderATP-Hunting-Queries). In this case, I’m just looking into all the events involving this particular file.

Another useful feature is the ”Collect investigation package”:

This will pull all sorts of useful information from the machine and allow you to download it in zip format. This can be very useful when doing the forensic analysis.

Reincarnation

So let’s say we’ve now concluded our investigations and cleaned up the machine. What next? We have to decrease the risk level of the machine for it to become compliant again. To do that, we have to resolve the alerts in the portal. You can also link alerts into incidents, as in this case all the alerts originating from this machine should all be related to a single incident.

Once all the alerts have been resolved, the risk level goes back to ”No known risks”. At this point, if we have isolated the machine, we could release it from the isolation (it took a couple of minutes for me to be able to reconnect my RDP session after the release).

And as expected, device status in Intune is back to compliant:

And I’m able to read my email again!

That concludes today’s experiments.