Author Archives: Joe Stocker

Microsoft increases email security market share 18%

Back in 2019, I wrote a blog post (here) explaining how to identify the primary DNS MX records used by the Fortune 500 and then use that to identify email security vendor market share. Then in 2020, I wrote a post that Microsoft had dipped 12% while others gained.

So when I ran the analysis again today, I was surprised to see that Microsoft had gained 14 new clients since the last time I had run the report two years ago. During that same time ProofPoint and Cisco also gained while Symantec and others lost market share amongst the Fortune 500.

image

I am asked all the time by customers “Is Microsoft “good enough?” Yes, but you don’t have to take my word for it. Microsoft just received the “AAA Protection Award” from SE labs—a testing lab focused on assessing the efficacy of security solutions. They evaluated email security vendors against a range of real-world email attack scenarios. They found 97 percent of emails that contained threats were blocked. That’s pretty good! Read more about Microsoft’s results here.

At the 2019 Microsoft Ignite Conference, there was a presentation (available on YouTube here) given where Microsoft made a pretty compelling case: since they sit behind other email security vendors (when mailboxes are hosted in Exchange Online) they can see when they could have blocked threats that others missed. In the graphic below, they claim to catch 400% more things than competitors!

image
MSFT misses 0.002% whereas competitors are missing 0.01% and 0.012% (that is a difference of 400%). To be sure, the competitors will make similar claims since Microsoft is unaware of their unique catch rates.

Industry analysts such as Forrester have named Microsoft a leader in email security (read the announcement here)

image

10 Reasons why I recommend Microsoft for Email Security

There are ten reasons why I recommend Microsoft email security to my clients:

  1. Automatic signal sharing with Microsoft Defender for Endpoint
  2. Protect malicious links in SharePoint, OneDrive, Teams, Office on the Web, and Microsoft 365 Apps for Enterprise
  3. Safe Documents
  4. Lateral Phishing Protection
  5. Native Link Rendering
  6. Anti-Phishing (prevent Business Email Compromise)
  7. Automatic Investigation and Response
  8. Threat Explorer
  9. Threat Hunting & XDR Integration
  10. Performance

Automatic signal sharing with Microsoft Defender for Endpoint

Whereas most other email security vendors create a silo of malicious file hashes when threats are detonated, Microsoft is able to share this information with Defender for Endpoint within milliseconds because they share a common back-end “the Intelligent Security Graph (PPT Download link).”

image

Protect malicious links in SharePoint, OneDrive, Teams, Office on the Web, and Microsoft 365 Apps for Enterprise

Whereas other email security products are typically limited to scanning only external emails, Microsoft is able to scan hyperlinks and attachments throughout the productivity applications. This is important because hackers often like to hide their malware in trusted locations such as OneDrive or SharePoint because most organizations cannot afford to block these root URLs since they are also used for business productivity.

Safe Documents

Safe Documents uses the cloud backend of Microsoft Defender for Endpoint (MDE) to scan documents opened in Microsoft Office. Users do not need to have MDE installed for this to work.

License Requirements: M365 E5 Security or full M365 E5. It is not included in the EOP or MDO license plans, you need the E5 Security step-up license (added to M365 E3) or the full M365 E5 suite.

Enable with PowerShell here:
Set-AtpPolicyForO365 -EnableSafeDocs $true –AllowSafeDocsOpen –$false

Learn more about Safe Documents in the Microsoft Documentation (here).

Lateral Phishing Protection

When mailboxes are hosted in Exchange Online, Microsoft is able scan internal emails, whereas other security vendors are usually limited to only when emails are external. Microsoft uses its advantage of hosting the email platform to perform this internal email scanning. This is valuable because if a hacker compromises an account, they will often use that to attack other internal accounts since it will look more trust worthy.

Learn how to configure safe link policies in the Microsoft Documentation (here)

Native Link Rendering

image
When email security vendors re-write the URL back to their service, they do so because they want to examine the hyperlink at the time of click for threats. Since Microsoft ‘owns’ the Outlook clients (mobile, web, desktop) then they can render the original URL when the user hovers over the link. This is helpful so that the user can use their security awareness training to better judge if the link appears suspicious. Other vendors cannot achieve this since they do not own the most popular email client used in the enterprise.

Read about the announcement of Native Link Rendering back in 2018 (here)

Anti-Impersonation in Anti-Phishing Policy to prevent Business Email Compromise

image

You can configure anti-impersonation for up to 350 users in a single policy (multiple policies are permitted). The idea is to protect your top executives from having their Display Name impersonated, or domain names that look similar to the domains you own. 

Learn more about how to enable Anti-Phishing in the Microsoft Documentation (here)

Automatic Investigation and Response

After a potentially malicious URL click is detected in email, or is manually reported by a User or Admin, or a SOC analyst who integrates AIR with their SIEM uses the Office 365 Management Activity API, then an automated playbook is launched to perform a deep investigation of these 13 steps:

1.Analyze user activity anomalies in Microsoft Cloud App Security, and check the attachment against Defender for Endpoint

2.On-demand check of domain reputation from Microsoft’s ISG and external threat intelligence sources

3.Detect anomalies based on historical mail flow sending patterns for users in your organization

4.Extract indicators from header, body and content of the email for investigation

5.Investigate mail delegation access for user mailboxes related to this investigation

6.Investigate any violations detected by Office 365 Data Loss Prevention (DLP)

7.Detect intra-org and outbound malware or phish originating from users in your organization

8.Investigate any mail forwarding rules for user mailboxes related to this investigation

9.Email cluster analysis based on (1) header, (2) body, (3) content and (4) URLs

10.On-demand check on URL reputation from Microsoft’s ISG and external threat intelligence sources

11.On-demand check of IP reputation from Microsoft’s ISG and external threat intelligence sources

12.Email cluster analysis based on outbound mail flow volume patterns

13.On-demand detonation triggered with Defender for Office 365 for emails, attachments and URLs

Then an Administrator is presented with an option to soft delete the emails:

image

Learn more (here).

Threat Explorer

Assuming you have permissions and licensing, you can navigate to Threat Explorer directly here: https://security.microsoft.com/threatexplorer

Threat Explorer is very powerful. You can:

  • See malware detected by Microsoft 365 security features
  • View phishing URL and click verdict data
  • Start an automated investigation and response process from a view in Explorer
  • Investigate malicious email, and more

Learn more about Threat Explorer (here).

Also the “Email Entity Page” is also helpful in investigations. Check it out (here). The Microsoft documentation is very good (much better than competitor products).

Threat Hunting & XDR Integration

If you know Kusto Query Language (KQL) then you can construct queries across inboxes, devices, identities, etc. You can also integrate with a SIEM such as Sentinel for true XDR. Sample queries:

  • Finds PowerShell activities that occurred right after an email was received from a malicious sender
  • Find the first appearance of files sent by a malicious sender among all devices or inboxes
  • Find emails containing open redirect URLs, for example:

EmailUrlInfo

| where Url matches regex @”s?\:\/\/(?:www\.)?t\.(?:[\w\-\.]+\/+)+(?:r|redirect)\/?\?”

  • Logons to a device after a malicious email was received, for example:

EmailEvents

| where Timestamp > ago(7d)

| where ThreatTypes has_cs “Malware”

| project EmailReceivedTime = Timestamp, Subject, SenderFromAddress, AccountName = tostring(split(RecipientEmailAddress, “@”)[0])

| join (

DeviceLogonEvents

| where Timestamp > ago(7d)

| project LogonTime = Timestamp, AccountName, DeviceName

) on AccountName

| where (LogonTime – EmailReceivedTime) between (0min .. 30min)

Learn more about advanced hunting (here)

Performance

The speed at which Microsoft can detonate attachments is impressive.

Most emails are detonated for threats within 5 to 12 seconds.

image

Can you imagine what it would take for you to build enough virtual machine capacity in your on-premises network to open every single email attachment received in a separate virtual machine to analyze behavior?

Here is a report you can use to analyze the latency introduced by Microsoft’s email security: https://security.microsoft.com/mailLatencyReport

Try it out

If you are using a 3rd party email security solution, you can begin to evaluate Microsoft Defender for Office now. You will need an E5 Trial subscription and you need to be a member of the Security Administrator and Exchange Administrator roles to set up the evaluation.
Learn more here: https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/try-microsoft-defender-for-office-365?view=o365-worldwide

Make the switch!

Already convinced? You can plan to make the switch from a 3rd party email security vendor to Microsoft by following the excellent documentation (here) or contacting a Microsoft Partner (such as Patriot! (My company!) – contact us at [email protected] for a quote!).

Azure AD Combined Registration (SSPR + MFA) is rolling out by October 2022

I’m starting to get questions from my customers about what to expect when the Azure AD “Combined Registration” feature is enabled beginning October 2022 and completing January 2023. On March 29th 2022 Microsoft published MC348869 in Message Center.

A bit of background: In April 2020, the combined security information registration experience for registering both multi-factor authentication (MFA) and self-service password reset (SSPR) was made available as an Opt-in feature but otherwise disabled by default.

We quickly encouraged everyone to enable it, for two primary reasons:

1. It simplifies the user experience so they register once instead of twice (when both MFA and SSPR are both used)

2. FIDO2 Security Key registration requires that the combined registration feature is first enabled. this is required if you want to go passwordless, as FIDO2 has use cases that augment WH4B and Authenticator app such as shared workstations or when employees don’t want to use their personal phones for authentication. It also adds URL binding so that users don’t get phished. But this isn’t a blog about FIDO2, I just can’t help use every opportunity to evangelize it – go use it now!

As you can see, even if you don’t use SSPR, it’s still valuable to enable the FIDO2 passwordless experience.

So does this change impact me?

Did you create your tenant after August 15th 2020? Then no, this change won’t impact you because any tenant created after that date already has Combined Registration enabled.

You can go check out to see if you have it enabled by following these instructions:

1. Sign into the Azure portal (portal.azure.com) with a privileged role such as “user administrator” or “global administrator.”
2. Go to Azure Active Directory > User settings > Manage user feature settings.
3. Under “Users can use the combined security information registration experience” – record the setting.

If it is not enabled for all users, then you can select an option to enable it for a pilot group so that you can record the new user experience , and then decide if you want to update your onboarding documentation.
Microsoft provides screen shots of the new experience here:
https://support.microsoft.com/en-us/account-billing/set-up-security-info-from-a-sign-in-page-28180870-c256-4ebf-8bd7-5335571bf9a8

Will there be any user impact?

Another customer recently asked me: “I use ADFS, and I do not have SSPR enabled, will this change impact me?”

Potentially yes. If your tenant currently does not have combined registration enabled, and you do not have SSPR registration currently required, then it is possible that if your SSPR authentication factors are not aligned to your MFA factors then I could imagine a scenario where users would be required to register for the SSPR factors when this change rolls out in October.

So my advice for everyone is to go into your SSPR authentication factors and try to align those with your MFA factors.

What makes this a confusing time (June 2022) is that there are three separate areas to configure factors.

1. Legacy MFA portal

image

2. SSPR Portal
Authentication methods selection in the Azure portal

3. Azure AD Portal – Authentication Methods

image

Eventually I expect these portals to be consolidated into the 3rd portal. Until then, sometimes users are not aware of all these locations to configure the authentication experience.

And recently, one of my customers was confused by the 3rd portal, thinking that “text message” had to do with using SMS as 2FA

image

No – remember this list of options are for passwordless authentication methods. So this text message option is for using your phone number instead of username, then you type in the code on your phone instead of a password (useful for retail environments where there is high employee turnover). Learn more about SMS-based authentication as an alternative to usernames/passwords in the Microsoft documentation here. Just because it is there, does *not* mean you should turn it on! Remember, SMS based authentication is weak! See Alex Weinert’s article “It’s Time to Hang Up on Phone Transports for Authentication.

Pre-registering MFA in M365

This article describes how to make the user onboarding experience into MFA as smooth as possible by pre-registering MFA methods.

Disclaimer: This article only applies to organizations that have decided to use Phone Number for verification. This is not recommended but in some organizations, they are unable to avoid this for a variety of reasons. If you want to learn why phone number verification is weak, check out the Microsoft Article: https://techcommunity.microsoft.com/t5/azure-active-directory-identity/it-s-time-to-hang-up-on-phone-transports-for-authentication/ba-p/1751752

The most ideal scenario would be to deploy Passwordless MFA, such as Windows Hello for Business, Authenticator App, FIDO2 Keys, or Certificate (Preview). You might issue a Temporary Access Pass to allow users to register passwordless methods without knowing the password to the account.

For more information on planning a passwordless deployment, click here: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-authentication-passwordless-deployment

Ever wonder what is required to pre-register a user for Phone or Email?

The “Authentication Methods” page displayed in Portal.Azure.com > Azure Active Directory > Users, allows you to pre-define the phone number that would be used for MFA.

image

If you use Always ON MFA, then you can set the user to Enforced. This can be automated with a GUI or PowerShell, or the preferred method would be to use a Conditional Access Policy (if you have Azure AD P1 or EMS E3 or M365 E3).

image

Their very first sign-in experience would be:

image

Otherwise, if you only populate the Mobile Phone field (such as in on-premises Active Directory, and then it synchronizes to Azure AD) then the user’s first sign-in experience will be to verify that the number shown is correct.

image

image

To populate the mobile phone using PowerShell, you can use PowerShell as described here: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-sspr-authenticationdata

But if you want to populate the Authentication Phone Number (so that the user can skip the registration page) then the PowerShell gets a little bit more involved.

Method 1 – Using PowerShell version 1 as described here: bulk Pre-registration for Azure MFA for more Seamless Single Sign on and smooth for MFA roll out – Microsoft Tech Community

Method 2 – Using MS Graph as described here: Pre-configure Authentication Methods for end users in Azure AD – Identity Man (identity-man.eu)

At this point I would strongly encourage you to enable number matching notifications and then enable the registration campaign.

Note: After September 30th 2022, the Combined Registration feature will be enabled in all tenants worldwide. This means that if you are using Self Service Password Reset, then the registration experience for users will be combined.
Therefore, instead of waiting until September, I would enable that feature now so that you can update your end-user facing documentation and user communications once rather than twice.
Learn more about Combined Registration here: Combined registration for SSPR and Azure AD Multi-Factor Authentication – Azure Active Directory | Microsoft Docs

Lapsus$ gains access to OKTA and Microsoft

Today (3/22/2022) both OKTA and Microsoft released statements about a threat actor named LAPSUS$ (Microsoft tracks as DEV-0537) who gained access to both organizations. In the last 90 days, this same threat actor has claimed victims including Impresa, NVIDIA, Samsung, Mercado Libre, Vodafone, and most recently Ubisoft.

In the case of Microsoft, the attack appears to be limited to portions of source code related to Microsoft’s Bing, Bing Maps, and Cortana.

“This week, the actor made public claims that they had gained access to Microsoft and exfiltrated portions of source code. No customer code or data was involved in the observed activities. Our investigation has found a single account had been compromised, granting limited access. Our cybersecurity response teams quickly engaged to remediate the compromised account and prevent further activity. Microsoft does not rely on the secrecy of code as a security measure and viewing source code does not lead to elevation of risk. The tactics DEV-0537 used in this intrusion reflect the tactics and techniques discussed in this blog. Our team was already investigating the compromised account based on threat intelligence when the actor publicly disclosed their intrusion. This public disclosure escalated our action allowing our team to intervene and interrupt the actor mid-operation, limiting broader impact.”

I recommend reading Microsoft’s write-up on this incident as it gives a detailed glimpse at the threat actor’s TTPs. For example, the threat actor is paying employees to gain access to victim networks.

However, in the case of OKTA, it appears the attack was more substantial based upon the 8 screen shots that LAPSUS$ made public (here).

The original official statement from OKTA seems to contradict what the hacking group is claiming.

“In January 2022, Okta detected an unsuccessful attempt to compromise the account of a customer support engineer working for a third-party provide”

https://sec.okta.com/articles/2022/03/official-okta-statement-lapsus-claims

The laptop of a support engineer appears to have been compromised. The attacker would have the ability to reset passwords and Multi Factor Authentication for users.

Then Zack Whittaker reported that OKTA reported 366 corporate customers were impacted.

https://techcrunch.com/2022/03/23/okta-breach-sykes-sitel/

Brian Krebs reported that the ringleader of LAPSUS may be a 17-year-old from the city of London, England, who goes by the handle WhiteDoxbin with a net work of $14 million (300 BTC).

https://krebsonsecurity.com/2022/03/a-closer-look-at-the-lapsus-data-extortion-group/

The BBC is quoting that seven people between the ages of 16 to 21 have been arrested.

OKTA Recommendations

1. If you are an OKTA customer, active Incident Response Plans, assume compromise happened between January 16 to 21

2. Collect and retain related logs. Okta System Logs are only available for a limited time (90 days) so you should download those immediately.

3. Hunt for evidence of suspicious password resets or changes to MFA on or around 1/16 to 1/21

4. Rotate Okta privileged passwords.

5. Look at the Okta Admin Console app in particular

legacyEventType eq “app.generic.provision.assign_user_to_app”

the “app.generic.provision” event type

and to identify any users granted access to other apps.

Another event worth checking on is “security.threat.configuration.update” to see any changes to Okta’s behavioral threat detection.

SIEM rules

https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/okta

https://github.com/elastic/detection-rules/tree/main/rules/integrations/okta

PowerPoint Rehearse with Coach

Today I discovered a PowerPoint feature called Rehearse with Coach.

Since I do lot of customer facing presentations, I thought I would give this a try and see what this feature is all about.

You can find it inside PowerPoint’s Slide Show Menu.

image

After clicking Record, then just talk to yourself a bit as if you were presenting to an audience. When you are done it will give you several tips for improvement, or in my case, validate that I am nailing it! j/k

image

– Pace is VERY important! 130 words per minute is just about right. Too fast, people can’t follow you. Too slow, then you’re boring!

– Fillers. This is something I struggle with a LOT. I often will use filler words like “ummmm” or “you know” without even thinking about it!

– Repetitive Language. I used to work with an employee who would say the phrase “business outcome” in every other sentence. It started to lose meaning because not everything has a business outcome!

– Inclusiveness. I sometimes catch myself saying “You Guys!”  This is a bad habit I am still trying to break and I look forward to improving in this area.image

– Pitch! Avoid being monotone! As you can see the longer I spoke, the more I drifted to the dreaded monotone!

– Originality.  Don’t just read the text on the slide, but instead use this as a guide for story telling!

Pretty cool stuff. I really appreciate how Microsoft continuously adds cool features like this into PowerPoint and other Office products.

Availability: Microsoft Apps for Enterprise Version 2012 (January 5 2021) https://docs.microsoft.com/en-us/officeupdates/current-channel#version-2012-january-05

More Information https://support.microsoft.com/en-us/office/rehearse-your-slide-show-with-presenter-coach-cd7fc941-5c3b-498c-a225-83ef3f64f07b

How to use Intune Device Enrollment Restrictions to block “Second Wave Phishing”

Microsoft recently published an article (here) describing a new phishing attack where attackers will attempt to bypass Azure AD Conditional Access Policies configured for ‘Require Compliant Device.”

image

When an attacker obtains the 1st factor credentials (username and password) they will be greeted by a warning message that informs them that they cannot sign-in due to a conditional access policy. But here is the irony,  the warning message informs the hacker exactly how to bypass the block, step by step! (To be fair, the warning message was designed to help users enroll their devices.. but still.. in this day and age, we don’t need to be giving novice hackers free advice on how to bypass our security controls!)

image

So after the attacker realizes that Conditional Access has been configured to require Intune Compliance, now all the hacker has to do is find a device to enroll into Intune. The attack consists of a hacker logging into a virtual machine they control somewhere, and then they Azure AD Join it to the target organization (with MDM Auto Enrollment), or Azure AD Register with Device Management (Intune) because they have obtained the username and password of the user. Perhaps the user had MFA enabled on their account, but the user has  accidentally authorized the attacker to logon via MFA Push Notification or Phone Call (this happens a lot actually, so you should switch users to Code Match, or wait for Microsoft to roll it out which is coming soon).

It’s worth noting that the way the article was originally written, it made it seem like the registration or Azure AD join itself would be a security concern, but it is not, because as soon as you reset the password of the user, then the primary refresh token is invalidated. Applications with Continuous Access Evaluation will be revoked within 15 minutes (at most) and legacy apps may take up to 60 minutes. You can also create an Azure AD Conditional Access Session policy to limit session lifetime too.

The other issue I had with the article is that it said the problem happens when MFA is not enabled for Device Registration or Azure AD Join. While this can help reduce the risk of it happening, it doesn’t prevent it. There is a better setting in my opinion that does a better job of preventing it which is blocking device registration of personal devices into Intune.

Endpoint.Microsoft.com > Devices > Enroll Devices > Enrollment Device Platform Restrictions

image

This is a setting that you can apply to All Devices, All Users, or you can scope to selected groups (devices or users). It will prevent the hacker from joining a device to Azure AD and then becoming auto-enrolled. The setting is called Enrollment Restrictions and you set it to block personally owned devices from enrolling into Intune (Ideally you would do this for all device types, not just Windows). This is what I recommend unless you have not yet configured Autopilot or other methods of enrolling devices into Intune. Otherwise, then you must follow the recommendation from the Microsoft article which is to require MFA for enrollment https://portal.azure.com/#blade/Microsoft_AAD_Devices/DevicesMenuBlade/DeviceSettings/menuId/

image

In my opinion, blocking personal device enrollment into Intune is by far the most secure way to go because it really cuts at the heart of what the attacker is trying to do which is to bypass the CA Policy that requires Intune Compliance. Remember: A rogue device that is AAD Registered or AAD Joined is not a threat to your organization, it’s better to think of it as an extension of the user’s identity that enables that user to achieve SSO. When there is no network transport to the internal network (no VPN) then it’s equally fragile to a password reset of the user’s credentials. Think of it this way: without Intune enrollment, these other device states cannot move laterally into the target network to perform the ‘second wave phishing campaign’ described in the Microsoft article. Or to be more verbose, since a Conditional Access Policy Grant Control cannot factor Registered Device or AAD Join device status, it can only filter based on Intune Compliance or Hybrid Domain Join.

The second option is to limit MDM auto enrollment is to scope specific groups rather than ALL users.

image

I don’t recommend this because it will have unintended side effects for things like Windows 365 or Autopilot.

What is Device Identity

One of the most confusing things about all of this is what is Device Identity in Azure AD?

Registered
Devices that are Azure AD registered are typically personally owned or mobile devices and are signed in with a personal Microsoft account or another local account.

Azure AD Joined
Devices that are Azure AD joined are usually owned by an organization and are signed in with an Azure AD account belonging to that organization. They exist only in the cloud. By default, nothing would prevent a user from being able to Join their personal machine in this manner (and that is why I believe Enrollment Restrictions to block “Personal Devices” are important to consider, as it would block people from Azure AD Joining their devices).

Hybrid Joined
Devices that are hybrid Azure AD joined are owned by an organization and are signed in with an on-premises Active Directory Domain user account belonging to that organization. This account is then in an OU that is synced to the Cloud, and Conditional Access Policies can then use this to device state as a Grant Control.

References:https://docs.microsoft.com/en-us/azure/active-directory/devices/overview#getting-devices-in-azure-ad 

See also https://o365blog.com/post/devices/

What prevents a rogue user from categorizing their personal device as corporate owned to bypass policy?

Or what if someone has no problem with their personal device being managed by their corporation? Maybe their organization pays them a stipend (this is becoming more and more common as a pseudo-BYOD or hybrid BYOD). In these scenarios, if you configured Device Enrollment Restriction then you will block an individual user from enrolling ANY device into Intune, since it will always default to personal. So then how would a user enroll a device? Short answer, by themselves they wouldn’t – they will need someone to pre-register it for them such as AutoPilot or an AD GPO to enroll Windows device as a corporate device. Other device types like iOS, Android, or macOS allow you to enter a serial number or IMEI but that option is not available for Windows.

Important Side Note: This forum post illustrates what happens when you configure enrollment restrictions to block Personally owned devices to Block but then neglect to manually change Autopilot devices to Corporate. They will get error 80180014 because they forgot to set the Autopilot devices to Corporate. https://techcommunity.microsoft.com/t5/microsoft-intune/error-80180014-due-to-device-restrictions-for-windows-autopilot/m-p/1155809

Seeing Device Enrollment Restriction in Action

If you attempt to enroll a device when Enrollment Restrictions are configured to block personal devices then there is no way I could find to circumvent this control, which is AMAZING because that is what we want to achieve to prevent a hacker from enrolling a device into Intune and bypassing Conditional Access Policies that limit authentication to only compliant devices.

image

Then in the Event Viewer Log Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin you will get Event ID 52

“MDM Enroll: Server Returned Fault/Code/Subcode/Value=(DeviceNotSupported) Fault/Reason/Text=(Device Identifier not preregistered).”

Require MFA for Device Registration

The Microsoft article states that enabling MFA for device registration would prevent this attack. The reason I don’t like this as the *only* control is because users can still accidentally approve a push notification, or they might have a man-in-the-middle phishing attack like EvilGinx. So keep this ON, but don’t rely on this as the *only* control.

image

If you want more granularity you can set the setting above to No and then configure it in Conditional Access Policy to force MFA when registering or joining

image

The Microsoft article also correctly points out that Intune enrollment can be restricted to an IP range via Conditional Access Policy. This would only work if remote users already have a VPN established with force-tunnel (whereas split-tunnel is much more common).

Summary

Relying on conditional access policies to requires compliant devices without also restricting enrollment into Intune through the various methods described in this article can lead to the attacker bypassing Conditional Access Policies that require Intune Compliance, leading to unauthorized access to SaaS apps or network resources. For example, in the worst case scenario, “Second Wave Phishing” would happen if Auto MDM Enrollment happens after an AAD Join or Device Reg (‘enroll only in device management”) setting, then a VPN configuration is automatically pushed down to the device, and then the AAD Joined machine is able to connect to other network resources. Ouch!

TIP

I should also point out that Microsoft recently created a Conditional Access Overview page that can help you spot other misconfigurations.

https://portal.azure.com/#blade/Microsoft_AAD_IAM/ConditionalAccessBlade/Overview

image

Get Help

Head over to the Microsoft Technical Communities to ask questions and get free peer support:

https://techcommunity.microsoft.com/t5/communities/ct-p/communities

I am always interested in feedback. If you feel I got it wrong or if you would do it differently please DM me on Twitter at @ITGuySocal

-Joe

OneDrive not starting up

Ok this was bizarre – we had a customer who had multiple machines where OneDrive for Business would not startup.

They swore that it was working fine. Never trust an end user.

The fix was to reverse a registry key which had disabled OneDrive, which in itself proves the users had no idea what they were talking about. Some administrator had rolled out a registry key to disable OneDrive, so there is no way it could have been working.

Always take what an end user tells you with a grain of salt. Like: a very very small grain.

Here was the fix to reverse the problem: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\OneDrive.DisableFileSyncNGSC set value to 0

Reboot

You are welcome =)

What happened to the Email Security Funnel Reports?

Don’t feel bad if you missed the September 20th 2021 blog post titled “Improving the reporting experience in Microsoft Defender for Office 365

To be clear, most of us only have time to read about user impacting things where features are being taken away as that typically draws our attention. So when we read a headline like this, we may put it on the backburner until we have time to get to it later.

Then comes the day when you start looking for your favorite report and you can’t find it! It’s missing!

image

Yes, Microsoft has retired SIX reports: the malware email detection report, the spam report, the safe attachment file types, and deposition report, the sent and received email report, and the URL trace report that previously lived in the exchange admin center.

But as bad as that sounds, it’s actually not that bad at all. Why? Microsoft has replaced the reports with new and better reports, you just need to know where to go look for it. Basically the Funnel Report has been replaced with a newer and more modern “Sankey” report.

https://security.microsoft.com/mailflowStatusReport?viewid=sankey

clip_image002

The report is interactive, so if you click on ‘impersonation’ it will expand like this:

clip_image002[5]

The other benefit of the new report over the old one is the filtering capability is significantly more robust.

“In order for SecOps to focus the scope of their assessment with a lot more granularity, we are providing security professionals the ability to filter data by organization domain, policy type and name, priority account user tag, recipient address and email directionality (inbound and outbound).”

The new report also has a cool new ‘trendline’ flyout report that appears on the right after clicking on ‘show trends’

clip_image004

clip_image006

Here is the documentation page describing all the new features and capabilities of the new report. What’s really helpful about the documentation is it describes that of the 6 reports that have been retired, it tells you the hyperlinks of how to find the information in the new reports!

https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/view-email-security-reports?view=o365-worldwide#mailflow-view-for-the-mailflow-status-report

Other benefits: PowerBI and reporting API integration, and data going back > 90 days. <- This is huge.

Summary

Yes, change is hard sometimes when you get used to going somewhere and then a blog article gets posted, you miss it, and now you cannot find your data. Normally, Microsoft adds banners inside the product letting you know that a dashboard is coming or you have 30 days to enjoy it before its gone, so I am not sure why that did not happen in this case, but I am sure we can all agree the new reports are better and we will all enjoy the 90 day + increased historical data that the reports will pull, increased filtering, better details and drill downs, etc.

Conditional Access Policy to Block Non-Compliant Devices

Recently came across a scenario where we needed to block access to everything in Azure Active Directory (AAD) for non-compliant devices. Setting up that Conditional Access (CA) Policy was not a problem. The problem was it worked too well, and it even blocked the ability to register new devices into Intune for them to get the appropriate compliance policies.

Here is the error we were receiving when trying to enroll devices:

clip_image002

Based upon this denial of access error we knew that the policy was too strict, and we needed to allow for enrollment of new devices to get compliant. We went back into our policy that was set to block all cloud apps and excluded Microsoft Intune Enrollment.

After saving the policy we then went into testing mode and then got this:

clip_image003

SAME ERROR!!!!!

We then investigated into the Microsoft documentation to try and find more information about Intune Enrollment and CA Policies. We stumbled upon this link that breaks down the steps required to configure a CA Policy for Intune enrollment with Multi-Factor Authentication (MFA)

https://docs.microsoft.com/en-us/mem/intune/enrollment/multi-factor-authentication

We do have MFA turned for our users in this environment, but this article only highlighted using the Microsoft Intune Enrollment app for MFA at enrollment. Our policy to block access was at least allowing for the MFA prompt to occur, but not enrollment. This example policy also is not blocking any other apps, just requiring MFA for the Windows Intune Enrollment app.

In the document we notice it mentioned another Intune app – called Microsoft Intune

clip_image005

Searching for Microsoft Intune will yield a plethora of information, but we needed the details on the cloud app. We then searched for the cloud app we found this link that identifies all the cloud apps available for CA Policies.

https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/concept-conditional-access-cloud-apps

Scrolling down it does list Microsoft Intune – but it has no link for more information on what it does! Microsoft Intune Enrollment is listed, and linked, but that link goes back to our MFA CA Policy link we from earlier!

Now that its all clear as mud, and we had to try something, we decided to also exclude Microsoft Intune as well as Microsoft Intune Enrollment. All cloud apps were still selected, and block access was still the condition.

clip_image007

Then select the two Intune Apps – Microsoft Intune Enrollment AND Microsoft Intune

clip_image009

We then tested again, and ENROLLMENT WAS SUCCESSFUL! By adding those two apps as exclusions the Policy blocks access to all non-compliant devices but still allows for new devices to enroll. This meets the need for this situation as we needed to block all non-compliant devices from accessing anything, but also giving them an opportunity to become compliant by registering with the tenant.

Let us know in the comments section if this helps or if you have another way of blocking access while allowing enrollment.

Thanks for reading!