Category Archives: Security

Everything you wanted to know about Security and Audit Logging in Office 365

There are four primary audit log locations in Office 365. Depending on license level, these logs have varying lengths of retention.

  1. Office 365 “Unified Access Log”
    1. Enabled by ‘opt in’ (The first time you visit the log page, it asks if you want to enable it.)
    2. Goes back 90 days
    3. Accessible here:
    4. Documentation: Search the audit log in the Microsoft 365 compliance center – Microsoft 365 Compliance | Microsoft Docs
    5. There are four options for extending the logs beyond 90 days
    6. Option 1: purchase M365 E5 (or other license) “Advanced Audit” which can extend this log to 1 year
    7. Option 2: purchase ‘10-Year Audit Log Retention Add On’ (this add-on first became available for purchase in March 2021). Note: This policy is *not* retroactive.
    8. Option 3: Extend this into Sentinel to get correlation and default query templates
    9. Option 4: Use a 3rd party SIEM to query the Office 365 Management API.
      TIP: When you purchase the “Advanced Audit” license, it will reduce the throttling that occurs when querying the API (so for example you will see data in Splunk much faster!).
    10. Option 5: PowerShell
  2. Azure AD Audit Log
    1. Enabled by Default
    2. Goes back 30 days with an Azure AD P1 license (or 7 days with an Azure AD Free)
    3. Accessible here: Azure Audit Log
    4. Documentation: Audit logs in Azure Active Directory | Microsoft Docs
    5. Latency. Audit logs have a latency ranging from 15 minutes to an hour
    6. Activities. A complete list of each activity audited is available (here)
    7. Limits. The export limit from the web interface is 5,000 records. You can get around this by exporting the logs through one of the options below, which can also be used to extend retention.
    8. Option 1: Extend this log into Azure Log Analytics (aka Azure Monitor) to go beyond 30 days (learn how here)
    9. Option 2: Extend this log into Sentinel to get correlation and default query templates (learn how here)
    10. Option 3: PowerShell or Graph API.
  3. Azure AD Sign-in log
    1. Enabled by Default
    2. Goes back 30 days with an Azure AD P1 license (or 7 days with an Azure AD Free)
    3. Accessible here: Azure Sign-in Log
    4. Documentation: Sign-in logs in Azure Active Directory | Microsoft Docs
    5. Latency. Sign-in activity logs can take from 15 minutes to up to 2 hours for some records. According to the documentation, 95% of all logs will show up in 2 minutes.
    6. Limits. The export limit from the web interface is 5,000 records. You can get around this by exporting the logs through one of the options below, which can also be used to extend retention.
    7. Option 1: Extend this log into Azure Log Analytics (aka Azure Monitor) to go beyond 30 days (learn how here)
      NOTE: Unlike the Azure Audit Log, the Azure AD Sign-in logs require an Azure AD P1 or higher license to export into Log Analytics.
    8. Option 2: Extend this log into Sentinel to get correlation and default query templates (learn how here)
    9. Option 3: PowerShell or Graph API.
  4. Microsoft Cloud App Security
    1. Goes back 6 months
    2. Not enabled by default, requires configuration. You must go to “Connected Apps” then click the three dots to make it include the additional log sources as shown here:
    3. Requires an M365 E5 license or O365 E5 license (or available via Stand Alone)
    4. Accessible here:
    5. Option 1: Extend this log into Sentinel to go beyond 6 months


There are a few really useful built-in reports that analyze the logs and produce findings.

  • Risky sign-ins – A risky sign-in is an indicator for a sign-in attempt that might have been performed by someone who is not the legitimate owner of a user account.

    Latency can range from as little as 5 minutes, to a maximum of 2 hours.

  • Users flagged for risk – A risky user is an indicator for a user account that might have been compromised
    Latency can range from as little as 5 minutes, to a maximum of 2 hours.
  • Risk Detections. Azure AD uses adaptive machine learning algorithms and heuristics to detect suspicious actions that are related to your user accounts. Each detected suspicious action is stored in a record called a risk detection.
    Here are the latencies associated with when the risk detections will appear:

Advanced Audit License

As noted above, the new Advanced Audit License extends the retention of the UAL audit log to 1 year and speeds up 3rd party API throttling. A 3rd useful capability is the additional fields that get audited when this license is applied to mailboxes. The ability to log the ‘MailItemsAccessed’ (some may know this as MessageBind, that is what it was called in on-premises Exchange). Additional entries including exactly which items were sent from the compromised account are also logged.

The Send event is also a mailbox auditing action and is triggered when a user performs one of the following actions:

  • Sends an email message
  • Replies to an email message
  • Forwards an email message

Investigators can use the Send event to identify email sent from a compromised account. The audit record for a Send event contains information about the message, such as when the message was sent, the InternetMessage ID, the subject line, and if the message contained attachments. This auditing information can help investigators identify information about email messages sent from a compromised account or sent by an attacker. Additionally, investigators can use a Microsoft 365 eDiscovery tool to search for the message (by using the subject line or message ID) to identify the recipients the message was sent to and the actual contents of the sent message. You can also run the Search-UnifiedAuditLog -Operations Send or Search-MailboxAuditLog -Operations Send commands in Exchange Online PowerShell.

The MailItemsAccessed mailbox auditing action covers all mail protocols: POP, IMAP, MAPI, EWS, Exchange ActiveSync, and REST.

This is useful in a forensic investigation because it logs which emails were accessed. Imagine the relief of a Legal team when a hacker only accessed 10 items instead of a million items, and none of those 10 items contained PII or PHI data.

Note: When a protocol such as POP, IMAP, or MAPI over HTTPS (aka Outlook Anywhere) syncs a folder, then a single audit event is logged that the folder contents were synced rather than an entry for each item in the folder. (Reference).

Note: If an attacker generates more than 1,000 audit records in 24 hours in a mailbox, then this audit log is paused for 24 hours =( So a crafty hacker could overwhelm the log in order to hide activities (the pause occurs for 24 hours). (Reference)


The SearchQueryInitiatedExchange event is triggered when a person uses Outlook to search for items in a mailbox. Events are triggered when searches are performed in the following Outlook environments:

  • Outlook (desktop client)
  • Outlook on the web (OWA)
  • Outlook for iOS
  • Outlook for Android
  • Mail app for Windows 10
  • Investigators can use the SearchQueryInitiatedExchange event to determine if an attacker who may have compromised an account looked for or tried to access sensitive information in the mailbox. The audit record for a SearchQueryInitiatedExchange event contains information such as the actual text of the search query. The audit record also indicates the Outlook environment the search was performed in. By looking at the search queries that an attacker may have performed, an investigator can better understand the intent of the email data that was searched for.

Similar to searching for mailbox items, the SearchQueryInitiatedSharePoint event is triggered when a person searches for items in SharePoint. Events are triggered when searches are performed in the following types of SharePoint sites:

  • Home sites
  • Communication sites
  • Hub sites
  • Sites associated with Microsoft Teams

Investigators can use the SearchQueryInitiatedSharePoint event to determine if an attacker tried to find (and possibly accessed) sensitive information in SharePoint. The audit record for a SearchQueryInitiatedSharePoint event contains also contains the actual text of the search query. The audit record also indicates the type of SharePoint site that was searched. By looking at the search queries that an attacker may have performed, an investigator can better understand the intent and scope of the file data being searched for.You can also run the Search-UnifiedAuditLog -Operations SearchQueryInitiatedSharePoint in Exchange Online PowerShell. You must enable SearchQueryInitiatedSharePoint to be logged so you can search for this event in the audit log. For instructions, see Set up Advanced Audit.

In additional to the events listed above, there are also unique audit events that are only audited when the Advanced Audit license is owned:


You can configure Alert Policies to notify you when certain things happen. This can be done in M365, Azure Monitor, MCAS, or Sentinel.

Audit Log Bypass

This article describes how it is possible for a user with administrative rights to bypass Mailbox audit logging, so be sure to document the configuration, and any changes to this configuration during a forensic investigation.

Manage mailbox auditing – Microsoft 365 Compliance | Microsoft Docs

PowerShell Modules

There are a variety of PowerShell modules available, designed to automate gathering the logs or searching them for use in forensic investigations. If you find any more, send me a DM on Twitter at @ITGuySocal

1. Hawk

2. DFIR-O365RC

3. Azure AD Toolkit (This is what Microsoft’s DART team uses)

4. CrowdStrike Reporting Tool for Azure (CRT)

5. Sparrow (this is what the US Government’s CISA’s Cloud Forensics team wrote back in December 2020 to identify activity in a tenant associated with the TTPs used by the hackers who compromised SolarWinds).

6. 365BlueTeamKit by Chaim Black

7. Office 365 Extractor by Joey Rentenaar and Korstiaan Stam from PwC Netherlands Incident Response team

8. Mandiant Azure AD Investigator This is similar to Sparrow in that it was built to  detecting artifacts that may be indicators of Nobelium/UNC2452/Sunburst or other threat actors that use those same techniques. 

Troubleshooting Windows 365 Business “Setup failed, please reset your Cloud PC”

My first attempt at Windows 365 Business failed with error message “Setup failed, please reset your Cloud PC.” I thought it would be as simple as assigning a license to a user.

Turns out there are a few additional configuration prerequisites that must take place.

The key is to understand that during the provisioning process, a new user account named CloudBPRT or “Windows 365 BPRT Permanent User” is created in Azure AD. This account is used to join the machine to Azure AD.

1. If you have a conditional access policy that requires MFA then you need to exclude the CloudBPRT user from the policy.
A great troubleshooting tip is to use the WhatIf tool and add the CloudBPRT user to see which CA policies are applying to the user and then exclude the user from these policies

2. In Device Settings you must disable the requirement to require MFA when doing Azure AD Join, and If you limit which users or groups can join Azure AD, you must add the CloudBPRT user (as shown below)


3. The CloudBPRT user must be assigned an Intune license if you are doing Intune Auto Enrollment

4. If you Configure MDM AutoEnrollment, you must make sure the CloudBPRT user is a member of the scope, or that it is set to ALL as shown below

5. Then, reset the Cloud PC

6. In my experience, after Cloud PC was reset, I also had to select Restart before I was able to logon, otherwise I got a blank screen when trying to connect to Cloud PC.


Reference: Windows 365 for Business Troubleshooting Documentation

Other tips:

  1. The device will automatically enroll into Intune as an Autopilot device, but there is no need to configure an Autopilot Enrollment Status Page, nor can you target an ESP to Cloud PC’s per Microsoft Documentation (here)
  2. The device may fail compliance checks since bitlocker is not supported on Cloud PC’s, so it will be necessary to create an Intune Filter for “Cloud PC” and exclude that from policies that require Bitlocker while requiring that filter for other settings so that you can pass conditional access policy checks. For instructions on how to create an Intune filter click (here)
  3. It can take several hours for Microsoft Defender for Endpoint to perform the initial sync of the risk level to Intune Compliance, so if your Intune Compliance Policy has the setting “Require the device to be at or under the machine risk score” then be prepared to adjust your “mark device as non compliant’ to have some grace period such as a day otherwise your new employee will be locked out after their first sign-in.
    “Once the connection is established, the services are expected to sync with each other at least once every 24 hours.” (reference here)

Security Concerns with Windows 365–aka Cloud PC

Cloud PC (sold as the Windows 365 Product SKU) is the latest Virtual Desktop service hosted by Microsoft in Azure. This post (Part 1) documents some of the security concerns that Infosec Twitter has identified. Part 2 will explore ways to harden CloudPC/Windows 365.

Cloud PC (Announced 7/14/2021 and Generally Available 8/2/2021)

Azure Virtual Desktop (Announced 6/7/2021) 

Windows Virtual Desktop (9/30/2019)

Azure RemoteApp (Retired on 8/31/2017)

Rand Morimoto wrote a nice write-up on Cloud PC (here), and the differences between it and Azure Virtual Desktop (here). Indeed, many have written articles on it, but the reason for this blog post is to examine the security and respond to some of the harsh criticism on Twitter (the InfoSec community on Twitter is probably the best ‘accountability’ buffer to keep Microsoft in check).

Most of what I have written about securing AVD/WVD (Part 1) and (Part 2) applies equally to Cloud PC. But what I love most about the business edition of Cloud PC is it eliminated all the overhead associated with spinning up the AVD/WVD environment (see Part 1 above to appreciate that effort). The Enterprise Edition requires some additional work but not as much as AVD/WVD, as explained in this Mechanics video here. There are already troubleshooting articles on the Hybrid Azure AD requirements here.

When I created my first Cloud PC, the provisioning process failed. I found out that there were issues with provisioning as described in the forums here. Turns out there were multiple issues and so I have published a separate blog post ‘Troubleshooting Windows 365 business’ here].

As an end user, you access your Cloud PC from:

Also, it’s worth noting that on August 15th 2021, Microsoft is making Cloud PC available for end users to purchase on their own credit cards. IT Departments can disable this with PowerShell.

Install-module MSCommerce


W365 Enterprise – update-MSCommerceProductPolicy -PolicyId AllowSelfServicePurchase -ProductId CFQ7TTC0HHS9 -Enabled $false

W365 Business/w Hybrid Benefits – update-MSCommerceProductPolicy -PolicyId AllowSelfServicePurchase -ProductId CFQ7TTC0J203 -Enabled $false

W365 Business – update-MSCommerceProductPolicy -PolicyId AllowSelfServicePurchase -ProductId CFQ7TTC0HX99 -Enabled $false”

Learn More: Use AllowSelfServicePurchase for the MSCommerce PowerShell module | Microsoft Docs

So why has Twitter been so unforgiving?

1. InfoSec Twitter does not like the default configuration of Local Administrator rights being given to the Cloud PC user. They claim this is not “secure by default.” It’s hard to argue with them on this point.
(1) Benjamin Delpy on Twitter: “Windows 365 is expensive and without basic security Did #mimikatz dumped my Azure *cleartext* password here? Or my Primary Refresh Token? It’s funny how you don’t apply best practices you recommend to the customer to avoid securing by default >” / Twitter
It does appear Microsoft is exploring solving this according to this thread here:
Windows 365 Business Cloud PC Local Admin – Microsoft Tech Community

2. Mimikatz has been updated to dump Windows 365 credentials

(1) Benjamin Delpy on Twitter: “After a little bug report from @LawrenceAbrams, I just pushed a #mimikatz fix to dump even more #Windows365 credentials privilege::debug ts::logonpasswords >” / Twitter


(1) Benjamin Delpy on Twitter: “Would you like to try to dump your #Windows365 Azure passwords in the Web Interface too? A new #mimikatz release is here to test! (Remote Desktop client still work, of course!) > cc: @awakecoding @RyMangan” / Twitter

3. Lack of SecureBoot, UEFI, Credential Guard, etc
(1) Benjamin Delpy on Twitter: “Figure 1. VM with hardware enforced security, vTPM, SecureBoot, UEFI, Credential Guard, etc. Figure 2. #Windows365 without basic hardware security, no security feature, BIOS Guess the one running on an old ESXi in basement vs the new 365 revolution from Microsoft in #Azure ?” / Twitter

Disable Exchange Online Remote PowerShell for users as a scheduled task

This PowerShell script can run unattended as a scheduled task and will enumerate the global administrators, then remove remote PowerShell access for any user who is not a global administrator.

#See Prerequisites section below to create these two certificate connection scripts below

Invoke-Expression -Command C:\scripts\connect-certificate.ps1

Invoke-Expression -Command C:\scripts\connect-azureadcertificate.ps1

$GlobalAdmins = Get-AzureADDirectoryRoleMember -ObjectId $(Get-AzureADDirectoryRole -filter “displayname eq ‘Global Administrator'”).ObjectID

$AllUsers = get-user -resultsize unlimited

$UserswithPowerShell = $AllUsers | where {$_.RemotePowerShellEnabled -eq $true}

$UsersWhoAreNotGlobalAdmins = $UserswithPowerShell | where {$_.userprincipalname -notin $GlobalAdmins.userprincipalname}

$counter = ($UsersWhoAreNotGlobalAdmins).count
$current = 1

if ($UsersWhoAreNotGlobalAdmins) {
write-host “Users who currently have remote powershell access” ($UserswithPowerShell).count
foreach ($user in $UsersWhoAreNotGlobalAdmins) {
write-host “Removing PowerShell access from user ” $current ” of ” $counter “(” $user.userprincipalname “)”
set-user -identity $user.userprincipalname -RemotePowerShellEnabled $false

#Optional, the next statement can also apply a authentication policy to block basic auth

#Set-User -identity $user.userprincipalname -AuthenticationPolicy “Block Basic Auth”
$current = $current + 1

write-host “there are no non-global admin users with PowerShell access”

Download the script (here).

Prerequisites: Create two Azure AD Applications (1) Exchange and (2) Azure AD

TIP: When creating the Scheduled Task,  the account must have the Logon as a service right assigned. Then the ‘action’ to start a program points to c:\windows\system32\windowspowershell\v1.0\powershell.exe
then the arguments are: -File “c:\scripts\scriptname.ps1”

Is your Exchange Hybrid Server internet-facing? You have likely already been hacked

– This is twice as big as the SolarWinds breach.

– Patching is not enough! If your Exchange Server was open to the internet via TCP 80 or 443 between February 26 and March 3rd (or later) assume it was compromised.

At least 30,000 organizations have had a backdoor installed on their Microsoft Exchange Server (on-premises).

We know it is at least this many because researchers have built an NMAP script to scan the internet for infected hosts.

There is nothing to indicate that Exchange Online has been impacted, but organizations in O365 could still have been hacked because most of those customers still have an internet-facing Exchange Hybrid server.

How to hunt for the existence of a backdoor known as a web shell.
(A web shell is an internet accessible web page that the hacker places on the Exchange Server that gives the attackers administrative access to the Exchange Server)

Indicators of Compromise 

<random_name>.aspx (often 8 characters)

In these directories:

o c:\inetpub\wwwroot\aspnet_client\

o c:\inetpub\wwwroot\aspnet_client\system_web\

o C:\Exchange\FrontEnd\HttpProxy\owa\auth\

o %PROGRAMFILES%\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\

– Signs of large amounts of SMB network traffic from the Exchange Server to internal network

– Scheduled Task on Exchange Server named Winnet

– Check for suspicious .zip, .rar, and .7z files in C:\ProgramData\, which may indicate possible data exfiltration.

– Monitor c:\root and c:\windows\temp for LSASS dumps (attackers used procdump64.exe) or rundll32 C:\windows\system32\comsvcs.dll MiniDump lsass.dmp

In some cases, additional dynamic link libraries (DLLs) and compiled aspx files are created shortly after the  webshells are first interacted with via POST requests in the following locations:

  • C:\Windows\Microsoft.NET\Framework64\<version>\Temporary ASP.NET Files\root\
  • C:\Windows\Microsoft.NET\Framework64\<version>\Temporary ASP.NET Files\owa\

Administrator is removed from the “Exchange Organization administrators” group (credit rapid7)

– Scan Exchange Logs for IOCs (manually here) or with the Microsoft script (here)

– You can also use this NMAP script to see if your servers are vulnerable after patching them.

In the attacks observed, the threat actor used these vulnerabilities to access on-premises Exchange servers which enabled access to email accounts and allowed installation of additional malware to facilitate long-term access to victim environments.

On March 6th, a security researcher created a honeypot with these vulnerabilities and found that it was exploited 5 times in less than 24 hours. This indicates several copy-cat threat actors are already targeting these vulnerabilities.

If you find evidence of compromise, activate your incident response procedures. You may have a legal requirement to notify within 72 hours of sensitive data was accessed in your email or network.

What versions are affected?

– Exchange 2013 Versions < 15.00.1497.012

– Exchange 2016 CU18 < 15.01.2106.013

– Exchange 2016 CU19 < 15.01.2176.009

– Exchange 2019 CU7 < 15.02.0721.013

– Exchange 2019 CU8 < 15.02.0792.010

– Microsoft issued CU 31 for Exchange Server 2010 – best to apply that, but it would be better to upgrade your hybrid server since Exchange 2010 normally does not receive security updates (this was a kind gesture on Microsoft’s part).

How do we prevent this from happening again?

– The only reason an Exchange Hybrid Server should still be internet-facing is if there are still on-premises mailboxes. Move those to the cloud and then shut off internet access to your hybrid server after moving the Autodiscover DNS record to point to

– If you have no on-premises mailboxes, you should close TCP 80/443 after moving Autodiscover to cloud

Learn more: Read the announcement, or view the Exchange blog. We also recommend the Volexity post (here) and Rapid7 post (here).

US Agencies and FireEye Were Hacked Using SolarWinds Software Backdoor

Multiple news sources are attributing the recent breaches (FireEye, the U.S. Treasury, and the U.S. Commerce Departments) to the same group: ATP29 Cozy Bear. The type of attack used is called a supply chain attack where a software vendor is targeted in order to breach the end-customer of that software. In this case, it was SolarWinds’ Orion Network Monitoring Software, which said their March and June 2020 software releases were compromised. Microsoft researchers have observed two files in October 2019 with code anomalies in the SolarWinds DLL, so it is possible that the initial access into SolarWinds may have occurred six months or longer before the malicious updates started spreading. The company estimates 18,000 of its 300,000+ customers may have installed the malicious update (this would make it the 2nd largest in history behind Citrix who had a similar attack happen to them with their install base of 400,000 customers – more on that later). SolarWinds is used by all five branches of the U.S. military, the Pentagon, State Department, Justice Department, NASA, the Executive Office of the President, the National Security Agency, the top 10 U.S. telecommunications companies, and 425 of the Fortune 500.
[Update 12/18/2020 So far Microsoft has identified 40 customers who may have been impacted, including Microsoft itself].
[Update 12/20/2020 A Chinese group called RedDrip posted on Twitter that they decoded the dynamically generated domain names that this malware used to communicate with C2, revealing the customer names that were hit. Others have used their code to post the customer lists on Pastebin (here and here).]

An emergency directive issued by the U.S. government agency Cybersecurity and Infrastructure Security Agency (CISA) calls on all federal civilian agencies to disconnect or power down SolarWinds Orion IT management tools because they are being used to facilitate an active exploit. Everyone else would be wise to follow this guidance too. CISA encourages affected organizations to read the SolarWinds and FireEye advisories for more information and FireEye’s GitHub page for detection countermeasures.

The Microsoft advisory from 12/13/2020 adds “if you suspect you are impacted you should assume your [email] communications are accessible to the actor” because the techniques observed including modifications to authentication to give persistence to email in Exchange Online, with clever techniques: “By impersonating existing applications that use permissions like Mail.Read to call the same APIs leveraged by the actor, the access is hidden amongst normal traffic.” Attackers apparently exported the private key from the ADFS token signing certificate and used that to forge SAML to gain access to cloud apps and on-premises resources. Therefore, if you use ADFS, you should consider changing the token signing certificate, or follow NSA’s recommendation to use Azure as the IDP instead of ADFS.

These supply chain attacks are not uncommon. In March of 2019 the FBI informed Citrix that they had been infiltrated for five months, as reported by Brian Krebs. In 2013, the US retailer Target was thought to be breached by a supply chain attack involving their HVAC system. In the Wipro’s data breach, hackers used ScreenConnect (ConnectWise) to gain access to their customer systems. NotPetya gained access through the accounting software M.E.Doc.

Since Microsoft’s Office 365 email may have been “an attack vector” used by the hackers, be sure to watch our best practices webinar series to secure your Office 365 environments. This is especially important if you are a software vendor for now obvious reasons, hackers want to use you to get into your customer installation base.

Always Assume Breach

Supply chain attacks highlight an important security principle: You should always assume that you have already been breached. For most organizations, it is not practical to review software update, nor would you have the original source code anyway. It’s better to just assume you have already been breached and adopt a mindset to always be ‘hunting’ for intruders. The attackers used signed binaries using Symantec certificate with thumbprint: 0fe973752022a606adf2a36e345dc0ed, meaning application control solutions that block unsigned executables would not have blocked the malicious backdoor from executing. According to this SANS video discussing the attack, the SolarWinds backdoor waits 12 to 14 days before sending its first beacon, presumably to avoid anti-malware sandbox detection or network-based behavioral learning periods.

Microsoft provides several tools that detect anomalous behavior, and provide hunting tools, including:  Azure Sentinel, Microsoft Defender for Endpoint, Microsoft Defender for Identity, and Microsoft Cloud App Security.
Note: Microsoft has already updated Microsoft Defender to detect the malicious code in the SolarWinds Orion product as “Trojan:MSIL/Solorigate.B!dha”.  My former colleague Matthew Dowst wrote a few hunting queries to detect the modifications to federation trusts and oAuth. [Update 1/4/2021]  CISA has published a tool to automate the detection (here). The issue is that the audit logs only go back so far (90 days unless Advanced Audit license was enabled).

[Update 12/23/20] For customers who had their Azure logs backing up to a Log Analytics (aka Azure Monitor) workspace then there is a new workbook that can help identify if suspicious activity in the tenant occurred.

  1. Modified application and service principal credentials/authentication methods
  2. Modified federation settings
  3. Azure AD STS Refresh token modifications by service principals and applications other than DirectorySync
  4. New permissions granted to service principals
  5. Directory role and group membership updates for service principals

Reference: Azure AD workbook to help you assess Solorigate risk – Microsoft Tech Community

[Update 12/24/2020] Just stumbled on this new guidance for Incident Responders from Microsoft here:

Advice for incident responders on recovery from systemic identity compromises – Microsoft Security

Includes some very helpful O365 forensic tools such as Hawk.

Need Help?

If you need expert assistance hardening Office 365, send us a request and we would be glad to help. Email us at Secure365 at

Does Defender scan USB drives?

No, not by default. But this isn’t as bad as it sounds! Here is Microsoft’s explanation from ~four years ago:

“Historically, antivirus products had a function to scan all files when a removable device was mounted. However, with the increase in device storage capacity, full scans of removable devices can noticeably and severely impact performance. Today, Windows Defender Antivirus performs quick scans on the contents of removable devices (such as USB drives), before the contents are copied, or executed. This approach both mitigates the risk that a malicious threat can infect the host through a removable device, while maintaining host performance. (A dormant file on a removable drive cannot infect a host). However, if needed, Windows Defender Antivirus can be configured to perform a custom scan on all files when removable devices are mounted. Below is a sample script for achieving this scenario Reference: TechNet Custom scan a USB drive (

And a more recent, albeit abbreviated explanation from November 2020:

“You can optionally run a PowerShell script to perform a custom scan of a USB drive after it is mounted, so that Microsoft Defender Antivirus starts scanning all files on a removable device once the removable device is attached. However, we recommend enabling real-time protection for improved scanning performance, especially for large storage devices. Reference: How to control USB devices and other removable media using Intune (Windows 10) – Windows security | Microsoft Docs

I tested the “scanusb.ps1” script and it failed to detect the sample malware file on a USB Drive.




Also, the CPU spiked to 13% for the duration of the scan on the large drive.


But as soon as you attempt to interact with the file then its immediately caught by the AV engine:


Also, be aware that The default behavior for scheduled scans is to not scan removable media. You can enable it with Group Policy or running this confusing double-negative PowerShell command: set-MpPreference -disableRemovabledrivescanning $false

Therefore, I agree with Microsoft with this design decision and I will be guiding my clients to stick with the defaults which protect the machine from malware while avoiding costly CPU hits. 

Defender for Endpoint (MDATP) for Windows Servers

[Update: 10/7/2021] Microsoft released to public preview a unified installer so that Windows Server 2012 R2 and 2016 now have a single installer for both AV and EDR. The prerequisite is to deploy MS KB5005292 first.
Read the announcement here:

Microsoft Defender for Endpoint (MDE) supports four versions of Windows Server: 2008 R2, 2012 R2, 2016, and 2019*

Windows Server 2016 was the first version of Windows to feature native antivirus protection “for free”. It was then called Windows Defender AV and is now called Microsoft Defender AV. This is not to be confused with what was then called Advanced Threat Protection (WDATP or MDATP), and what was recently renamed Microsoft Defender for Endpoint. Back then the ATP added Endpoint Detection and Response (EDR) on top of the AV/EPP. And it was originally available through a separate “Azure Security Center” (ASC) subscription for approximately $15/server/month. However in 2020, Microsoft began to sell EDR for servers for $4.99/server/month (I believe the minimum QTY is 50 servers, contact a MSFT CSP or License Reseller for an exact quote). Note: At the Ignite 2020 conference, Microsoft rebranded parts of Azure Security Center to “Azure Defender” (reference).

But what if you needed a antivirus for earlier versions of server operating systems such as 2012 R2 or 2008 R2? Back then your option was System Center Endpoint Protection (SCEP), or if it is hosted in Azure you can deploy the free “Microsoft Antimalware for Azure” (MAA) which is the same antimalware platform that SCEP uses. The SCEP AV client is managed  with Group Policy or SCCM. See Yong Rhee’s blog here for more details on down-level client management (I included some details from his blog in the management section below).

There are three unique deployment scenarios for protecting Windows Server Operating Systems:




2008 R2 Yes Yes (N/A)
2012 R2 Yes Yes (N/A)
2016 No Yes Natively Installed
2019 No No Natively Installed

Scenario 1) Windows Server 2008 R2 and 2012 R2.

Separate deployment of SCEP (or MAA) (to get AV and EPP), and then the Microsoft Management Agent (MMA) to get EDR from the Microsoft Defender for Endpoint management console (

System Center Endpoint Protection (SCEP) can either be  distributed using GPO, System Center Configuration Manager (SCCM), or any software distribution tool of choice. SCCM is not a requirement to use SCEP but you must have access to the Endpoint Protection client installation package, scepinstall.exe. Find this package in the Client folder of the Configuration Manager installation folder on the site server.

Microsoft Defender for Endpoint (formerly known as MDATP) provides the EDR agent (aka MMA, or Microsoft Management Agent) and you would distribute this using SCCM, Group Policy, or your software distribution tool of choice.

The MMA agent has a prerequisite hotfix which should be on your servers if you apply all recommended updates. If you have some older servers that are infrequently patched, be sure to install the prerequisite hotfix (here).

MAA for Azure virtual machines offers a lightweight management option when first deploying to servers, with no central management, so its something to consider perhaps for a DMZ.


Scenario 2) Windows Server 2016

No need to deploy SCEP because Defender AV is natively built-in.

But you must deploy MMA either through Azure Defender or Microsoft Defender for Endpoint management console ( > Settings > Onboarding.

Scenario 3) Windows Server 2019

No need to deploy SCEP because Defender AV is natively built-in.

No need to deploy MMA, because EDR is natively built-in.  Since there is no MMA to deploy, Azure Defender (aka Azure Security Center) does not automatically onboard Windows Server 2019, and therefore it is mandatory at the time of this writing to onboard using the instructions in Microsoft Defender for Endpoint management console ( > Settings > Onboarding.

Microsoft Defender AV Management Settings

In Windows 10, Windows Server 2016, and Windows Server 2019, use the Group Policy (GPO) :

Computer Configuration –> Administrative Templates –> Windows Components –> Windows Defender Antivirus

This modifies the following registry key: Hkey_Local_Machine > Software > Policies > Microsoft > Windows Defender

However, in Windows Server 2012 R2, Windows 8.1, Windows Server 2012, Windows 8, Windows Server 2008 R2 SP1, Windows 7 SP1, Windows Server 2008 SP2, Windows Vista, you use a non-existent Group Policy (GPO):

Computer Configuration –> Administrative Templates –> Windows Components –> Endpoint Protection

This modifies the following registry key: Hkey_Local_Machine > Software > Policies > Microsoft > Microsoft Antimalware

So how do you get “Endpoint Protection” to show up? For this, see the procedure here: Manage Endpoint Protection using Group Policies – Configuration Manager | Microsoft Docs

Some IT Departments do not run traditional “AV” or “EPP” on their Windows Servers. They have their reasons, but its typically based on a threat model where if a strong firewall is deployed on server to prevent inbound communications, then the theory is that threats shouldn’t wind up on the server. The issue with this is GPO and other software distribution tools – you want some layered option to block threats from getting distributed via alternate means. So I do recommend SCEP for down-level servers.


*Server 2019 is also known as Long-Term Service Channel (LTSC). While MDE also supports the Semi-Annual Channel (SAC) versions of Windows Server, it is beyond the scope of this blog article to discuss the pros and cons of SAC (instead refer to Comparison of Windows Server Servicing Channels).

Defender for Endpoint on iOS

The public preview of Defender for Endpoint on iOS can be installed by browsing to

Prerequisites: iOS 11.0 or higher, and the mobile device has Intune Company Portal App.

Lesson Learned: If you have the Azure AD Conditional Access policy enabled “Require Compliant App” then you need to exclude the Microsoft Defender app from the policy otherwise you will receive this message:


Smishing is, essentially, phishing via text messages. The word is a combination of “phishing” and “SMS,” the latter being the protocol used by most phone text messaging services.


Microsoft Defender for Endpoint creates a local VPN tunnel that redirects all outbound traffic that originates from the device to be scanned for threats, specifically websites that are malicious.


Here is an example of the block page:


Then Administrators can view these events in the Defender security portal (


You can also block specific websites or even categories of websites such as Shadow IT if you have Microsoft Cloud App Security. See Matt Soseman’s video on Youtube (here) for more information about that integration.

What happened to Defender running in a Sandbox? MP_FORCE_USE_SANDBOX

A colleague asked me today “Does Microsoft Defender run itself in a sandbox by default, or does that need to be manually enabled?”

He was referring to a breakthrough feature first announced (here) two years ago (10/26/2018)

We all know Defender can detonate files in a cloud sandbox – but we are talking about Defender running *itself* (MSMPENG.EXE) inside a sandbox.

This was a big deal at the time it was announced, because Defender was the first Antivirus product to run *itself* in a sandbox. I had read reports that 30% of all malware targeted security software since it runs with such high privileges, so this was and is a very big deal.

Running Windows Defender Antivirus in a sandbox ensures that in the unlikely event that Defender itself has vulnerabilities and becomes compromised, malicious actions are limited to the isolated environment, protecting the rest of the system from harm, since Defender runs with such high system privileges.

This feature is enabled with a machine-wide environment variable (setx /M MP_FORCE_USE_SANDBOX 1) and then restarting the machine (System requirement: Windows 10, version 1703 or later)

How can I tell if Defender is running itself in a Sandbox? Check task scheduler and if you see “CP.exe”


Sysinternals will show “App Container” 


You can also run CMD.exe followed by the SET command by itself to see if the environment variable is present:


So the question is, has Microsoft now built this into the operating system by default?

I created some fresh Win10 VM’s with Defender and did not see the CP.exe tailing process name.

So my big question is: why after two years hasn’t it been turned on by default? Is Microsoft aware of any risks or problems when this is enabled? And why is there no MEM/Intune configuration to enable this setting?