Microsoft Defender

Microsoft Defender

Microsoft rebrands its enterprise security solutions to Microsoft Defender. Microsoft Defender is a holistic solution for what is known as Extended Detection and Response. This blog post will explain what is meant by Extended Detection and Response and go through the Microsoft Defender security name changes.

Extended Detection and Response is a solution that provides threat detection across multiple domains rather than the single point of view that Endpoint Detection and Response delivers. Endpoint Detection and Response uses machine learning and behavioral analysis to detect zero-day vulnerabilities looking at the behavior across a single security layer. Extended Detection and Response enables telemetry and behavioral analysis across numerous security layers.

Two Extended Detection and Response products from Microsoft Defender are Microsoft 365 Defender and Azure Defender. Microsoft 365 Defender is not a new product in the family. Microsoft 365 Defender is known as Microsoft Threat Protection. Microsoft 365 Defender uses a single unified portal, cross-domain hunting, for four products: Microsoft Defender for Identity, Microsoft Defender for Endpoint, Microsoft Defender for Office 365, and Microsoft Cloud App Security.

Microsoft Defender – Extended Detection and Response

Here is an example of an Extended Detection and Response incident: Suppose a potential threat identifies in Microsoft Defender for Office 365 as a “Potential phishing attack,” and around the same time, a potential threat is identified on the endpoint by Microsoft Defender for Endpoint. In that case, Microsoft 365 Defender will determine the risk and raise an alert, and creates an incident. The threat is not classified as potential anymore but as an incident due to detection across multiple domains.

Another added value of Extended Detection and Response is aggregation. Multiple threat encounters across various domains aggregates to less and manageable alerts, and those alerts aggregate to less and manageable incidents. Using aggregation, Security Operations Center does not need to go through all threat encounters, but they can focus on the more critical incidents. Using Microsoft 365 Defender makes it possible to execute advanced hunting using Kusto Query Language across multiple domains as well.

Last but not least, a reminder of the name changes within Microsoft Defender.

New product nameOld Product name
Microsoft Defender for IdentityMicrosoft Azure ATP
Microsoft Defender for EndpointMicrosoft Defender ATP
Microsoft Defender for Office 365Microsoft Office 365 ATP
Microsoft 365 DefenderMicrosoft Threat Protection
Azure Defender for ServersAzure Security Center Standard Edition
Azure Defender for IoTAzure Security Center for IoT
Azure Defender for SQLAdvanced Threat Protection for SQL
Microsoft Products Name Changes

Conclusion

Although Microsoft 365 Defender is not new, I like Microsoft 365 Defender as an Extended Detection and Response solution. The aggregation of alerts and advanced hunting makes it possible to get a better and more precise insight within the environment.

I had to get used to the name changes, but I am thrilled that Microsoft changes their products to a simpler naming scheme.

Microsoft Log Retention Overview

Microsoft Log Retention Overview

For most Microsoft products, data retention is 30 days. However, it depends on some products if you use the free or paid version of the product, and some products do not allow you to change to the retention period at all. To get a clear overview, I created a table with the most common Microsoft products with their retention period.

Microsoft Log Retention

ProductReportMinimumMaximumDefault
Microsoft Azure AD FreeAudit Logs7 days7 days7 days
Microsoft Azure AD FreeSign-in Logs7 days7 days7 days
Microsoft Azure AD FreeAzure MFA Usage30 days30 days30 days
Microsoft Azure AD FreeUsers at risk7 days7 days7 days
Microsoft Azure AD FreeRisky sign-ins7 days7 days7 days
Microsoft Azure AD PremiumAudit Logs30 days30 days30 days
Microsoft Azure AD PremiumSign-in Logs30 days30 days30 days
Microsoft Azure AD PremiumAzure MFA Usage30 days30 days30 days
Microsoft Azure AD Premium P1Users at risk30 days30 days30 days
Microsoft Azure AD Premium P1Risky sign-ins30 days30 days30 days
Microsoft Azure AD Premium P2Users at risk90 days90 days90 days
Microsoft Azure AD Premium P2Risky sign-ins90 days90 days90 days
Microsoft Defender for EndpointData Retention30 days180 days180 days
Microsoft Cloud App SecurityActivity Logs180 days180 days180 days
Microsoft Cloud App SecurityDiscovery Data90 days90 days90 days
Microsoft Cloud App SecurityAlerts180 days180 days180 days
Microsoft Cloud App SecurityGovernance Logs120 days120 days120 days
Microsoft Defender for IdentityAudit Logs90 days90 days90 days
Microsoft Defender for Office 365 P1Real-time Detections30 days30 days30 days
Microsoft Defender for Office 365 P2Threat Explorer30 days30 days30 days
Microsoft Azure Log Analytics FreeData Retention30 days30 days30 days
Microsoft Azure Log Analytics PaidData Retention30 days730 days30 days
Microsoft Office 365Basic Audit Logs90 days90 days90 days
Microsoft Office 365Advanced Audit Logs365 days365 days365 days
Microsoft Office 365Message Trace90 days90 days90 days
Microsoft Log Retention Overview

Conclusion

Not all products allow you to change the retention period, and some products come with an additional cost when changing the retention period. However, this is not always the case. When a Log Analytics Workspace is attached to Sentinel, data retention if free for 90 days.

Suppose you want to extend the retention period longer than the maximum period. In that case, you need to send the logs to a Security Information and Event Management (SIEM) solution or send it to an Azure Log Analytics workspace if the product supports it.

Microsoft Office 365 Incident Response using the Microsoft Graph Security API

Microsoft Office 365 Incident Response using the Microsoft Graph Security API

During an incident, you want to do your analysis as quickly and as precisely as possible. Although there are many scripts available to do proper research within Microsoft 365, if you are working with Exchange Online, OneDrive, SharePoint, they all need separate modules. Not to mention that Exchange Online sometimes need multiple modules depending on what data you want to extract. Using numerous modules can be a pain due to numerous logins that are required.

I wanted to create a ‘One ring to rule them all’ for any incident response within Microsoft 365, which is Operating System independent, runs natively on Windows, and works with or without Multi-Factor Authentication. PowerShell runs on Linux, macOS, natively on Windows, and it happens to be a language I somewhat understand.

Since many Microsoft security products and services connect to the Microsoft Graph Security API, I have chosen to use PowerShell in combination with the Microsoft Graph Security API.

App Registration

To communicate to the Microsoft Graph Security API, you need an app registration. If you create an app registration, be sure you select the Microsoft graph and Application Permissions.

Note: During the application registration, write down the application ID, the client secret, and the tenant name.

Azure AD API Permissions Microsoft Graph
Azure AD Permissions Applications Permissions

Add the following API permissions.

    Directory.Read.All
    Directory.ReadWrite.All
    IdentityRiskyUser.Read.All
    Policy.Read.All
    SecurityEvents.Read.All
    DelegatedPermissionGrant.ReadWrite.All
    AuditLog.Read.All
    Mail.Read
    MailboxSettings.Read

Research Questions

The idea of answering a research question is to run a function, export the outcome to a JSON file, and filter the JSON file if needed. The sign-in logs, for example, contain a lot of information. Using your favorite tool, you can extract what research question you would like to answer. The export includes the location of the login. A simple query makes it possible to filter all logins outside the company’s country to get an overview of potential malicious logins.

RR-GetAccessToken

The first thing you need to do is getting a token using the app registration you created previously.

RR-GetAccessToken -appId 'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX' -appSecret 'XXXXXXXX' -tenantName "thalpius.onmicrosoft.com"

Once you have a token, you can use the functions described below.

Note: The token expires in one hour. I have not had this issue myself that a function runs more than an hour, but I am looking to add a refresh token to the script. You can always request a new token described above, which is valid for another hour.

RR-GetSkus

The first thing to look for is licenses. If the tenant contains an Office 365 Advanced Threat Protection license, it helps during the investigation. Or if the tenant contains an Azure AD Premium license, you know the logs in Azure AD go back one month instead of seven days.

I recommend starting with an output of the licenses to see what tools can help during the investigation.

RR-GetSkus

RR-GetAcceptedDomains

Accepted domains are used in the tenant to sent and receive e-mail. The function RR-GetAcceptedDomains can extract all accepted domains within the tenant.

Getting all accepted domains is helpful to validate which domain names accept e-mail within the tenant.

RR-GetAcceptedDomains

RR-GetInboxRules

Many attackers create inbox rules for persistence or hiding footprints. With the function RR-GetInboxRules you can export all inbox rules within the tenant or for a particular user.

RR-GetInboxRules
RR-GetInboxRules -userPrincipalName user@thalpius.com

RR-GetSignins

The RR-GetSignins functions export all Azure AD sign-ins within the tenant or for a particular user. The sign-in logs contain a lot of information like the user-agent, location of the sign-in, etc.

RR-GetSignins
RR-GetSignins -userPrincipalName user@thalpius.com

RR-GetAuditLogs

The RR-GetAuditLogs functions export all Azure AD audit logs within the tenant or for a particular user.

RR-GetAuditLogs
RR-GetAuditLogs -userPrincipalName user@thalpius.com

RR-GetEmailBySubject

The function RR-GetEmailBySubject searches for any e-mail with a given subject.

RR-GetEmailBySubject -subject "thalpius"

RR-GetEmailByBody

The function RR-GetEmailByBody searches for any e-mail with a given keyword in the body of the e-mail.

RR-GetEmailByBody -bodyKeyword "thalpius"

RR-GetAttachment

This function gives you the ability to extract all usernames with a given attachment filename in their mailbox.

RR-GetAttachment -fileName "thalpius.zip"

RR-GetAttachments

This function gives you the ability to extract attachments to check if it is malicious. It exports all attachments from a user’s mailbox or extracts the attachment itself if you use the attachmentId. The attachment is Base64 encoded. Decode the encoded string in the output to get the binary.

RR-GetAttachments -userPrincipalName user@thalpius.com
RR-GetAttachments -userPrincipalName user@thalpius.com -extension ".zip"
RR-GetAttachments -userPrincipalName user@thalpius.com -attachmentId XXXX-XXXXXX-XXXX

RR-GetAllAppRegistrations

In an illicit consent grant attack, the attacker creates an Azure-registered application that requests access to data such as contact information and e-mail. This function exports all app registrations within the tenant, including the owner.

RR-GetAllAppRegistrations

RR-OutputArray

Every function adds the data to an array. Once you are done running all functions you think you need, RR-OutputArray creates a JSON file with all data. You can filter the data if needed using your favorite scripting language.

RR-OutputArray -outputLocation 'c:\users\thalpius\incidentResponse\output.json'

Conclusion

Check out the script on my GitHub page. If you are missing any research questions, please let me know or add a GitHub issue and I will do my best to add it to the script.

Note: Do not forget to remove the Microsoft Graph Security API permissions once the investigation is completed.

Microsoft 365 Top 5 Security Best Practices

Microsoft 365 Top 5 Security Best Practices

According to Microsoft, using Multi-Factor Authentication reduces 99,9% of account compromise attacks within Microsoft 365. Many companies know Multi-Factor Authentication is the right security solution, but what about other security measures?

Here are my top five security measures any company needs to take within Microsoft 365. I even made a downloadable infographic about it.

Infographic

Security Awareness

I want to start by saying that security awareness could easily be number one. I wanted to create a technical top five, but I can not miss out on security awareness as it is essential within any company.

Any given employee needs to be able to identify a threat. Security awareness training helps raise employees’ awareness to identify risks, and the employee then knows what to do when it comes to handling the threat or who to contact.

Security Operations Center

One of the most significant benefits of having a Security Operations Center (SOC) is twenty-four seven monitoring. Hackers do not have a nine to five mentality nor work from Monday till Friday. Is there a follow-up on a security threat on a Saturday at ten PM, or do you have to wait for employees to complain on Monday that they can not access their data due to ransomware? Monitoring your environment twenty-four seven is crucial within any company.

SPF, DKIM and DMARC

Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) are configurations to lower incoming phishing e-mail delivered in the inbox of the user. It is relatively easy to implement and does not come with additional costs. Since a lot of attacks use phishing, implementing SPF, DKIM, and DMARC is a must.

Multi-Factor Authentication and Legacy Authentication

Multi-Factor Authentication and Legacy Authentication go hand in hand since Legacy Authentication does not support Multi-Factor Authentication. So implementing Multi-Factor Authentication is not enough as Legacy Authentication should be disabled as well.

According to Microsoft, more than 99 percent of password spray attacks use legacy authentication protocols, and using Multi-Factor Authentication reduces 99,9% of the attacks within Microsoft Office 365.

In combination with secure awareness, Multi-Factor Authentication and disabling Legacy Authentication is a must within any Microsoft 365 environment.

Conclusion

There are many security measures a company can take. In my opinion, these are the five minimum Microsoft 365 security measures every company needs to take.

Microsoft Office 365 Multi-Factor Authentication

Microsoft Office 365 Multi-Factor Authentication

There are multiple ways to enable Multi-Factor Authentication (MFA) within Microsoft Office 365. This blog post will describe the various technical implementations of Multi-Factor Authentication, including the best-practice to implement it.

Azure AD MFA Per User

There are three Multi-Factor Authentication statuses within Microsoft Office 365: Enabled, Enforced, and Disabled. The status Enabled indicates that Multi-Factor Authentication is enabled, but the user did not go through the Multi-Factor Authentication registration yet. When the user goes through the Multi-Factor Authentication registration, the status changes to Enforced. Disabled means that Multi-Factor Authentication is not enabled, and the user does not have to log in with a Multi-Factor.

The risk by enabling Multi-Factor Authentication on a user-basis is misconfiguration since Multi-Factor Authentication is not enabled by default when creating a new user account. An administrator can forget enabling Multi-Factor Authentication, which increases the risk of a successful password attack due to missing Multi-Factor Authentication.

Azure AD MFA via Conditional Access

Conditional Access policies at their simplest are if-then statements; if a user wants to access a resource, then they must complete an action. An action can be Multi-Factor Authentication. With Conditional Access, you force every user to use Multi-Factor Authentication when logging into Microsoft Office 365. Using Conditional Access, the risk of misconfiguration lowers since every user applies to the Conditional Access when logging in, and its the best-practice to enable Multi-Factor Authentication.

Note: Azure AD Conditional Access is part of the Azure AD Premium licensing model. So additional costs are required.

Azure AD Named Locations

You can add trusted IP address ranges within Azure AD as Named Locations. A policy can then exclude the Named Locations. Using an exclusion can prevent an identity from being challenged with Multi-Factor Authentication if it comes from a trusted location.

Azure AD Identity Protection MFA Registration Policy

The advantage of using the Multi-Factor Authentication policy within Azure AD Identity Protection is that users have 14 days to complete the registration. During these 14 days, they can bypass registration, but they have to register before they can complete the sign-in process at the end of the period. Once the sign-in process is complete, the user can log in without Multi-Factor Authentication. The policy only forces a user to register Multi-Factor Authentication. The Azure AD Identity protection policy is unnecessary when Multi-Factor Authentication is enforced using Conditional Access.

Note: Azure AD Identity Protection is part of the Azure AD Premium licensing model. So additional costs are required.

Azure AD Security Defaults

If you do not have an Azure AD Premium license or do not want to buy any additional license, Azure AD Security Defaults is a good alternative.

Enabling this option configures your organization with the following settings:

  • Requiring all users to register for Azure Multi-Factor Authentication;
  • Requiring administrators to perform multi-factor authentication;
  • Blocking legacy authentication protocols;
  • Requiring users to perform multi-factor authentication when necessary;
  • Protecting privileged activities like access to the Azure portal.

Note: Azure AD Security Defaults are not suitable for complex security requirements. It is either turned on or turned off. If you want to make decisions based on a condition, Conditional Access is the way to go.

Legacy Authentication

Microsoft Azure Active Directory supports several authentication and authorization protocols, including legacy authentication. Legacy authentication includes Exchange ActiveSync, SMTP, Autodiscover, Exchange Web Services, POP3, IMAP4, and many more.

The problem is, legacy authentication does not support Multi-Factor Authentication!

According to Microsoft, more than 99 percent of password spray attacks use legacy authentication protocols. It is crucial to disable legacy authentication when using Multi-Factor Authentication or in any situation.

You can use the Azure portal to identify the usage of legacy authentication within your environment before disabling it.

  1. Navigate to; Azure portal > Azure Active Directory > Sign-ins.
  2. Add the Client App column if it is not shown by clicking on; Columns > Client App.
  3. Add filters > Client App > select all of the legacy authentication protocols. Select outside the filtering dialog box to apply your selections and close the dialog box.

Note: Conditional Access in Report-only mode is another way to identify legacy authentication within your environment.

Conclusion

According to Microsoft, using Multi-Factor Authentication reduces 99,9% of the attacks within Microsoft Office 365. Using Multi-Factor Authentication does not mean your company is safe for password attacks. It would not be the first time a user accepts a Multi-Factor Authentication challenge on their device when an attacker logs-in within Microsoft Office 365 with leaked credentials. So adoption and education for company users are critical. Enabling Multi-Factor Authentication and disabling legacy authentication is a minimum security measure every organization should take.