How to disable diagnostic data from being sent to Microsoft in Windows 10 and Office

I have never put much thought into disabling diagnostic data from being sent to Microsoft, because I’ve always given them the benefit of the doubt that they benefit from using this data to identify faulty drivers and things that cause reliability issues in Windows. However, according to Microsoft, this data may contain “personal data” as defined by Article 4 of the European GDPR (more on that below) and therefore our friends in Europe have asked for guidance on how to disable this diagnostic data from being sent to Microsoft.

If you want to see what type of information is being sent to Microsoft, Windows 10 now includes the ability to view the diagnostic data by downloading a tool called the Diagnostic Data Viewer.

Step 1. Enable the Viewing of Diagnostic Data in Windows 10 (full documentation is here)

Step 2. Download the Diagnostic Data Viewer tool from the Microsoft App Store

Step 3. Launch the tool to review the diagnostic data that was sent to Microsoft.

According to this Microsoft Support article (here)

“Diagnostic data may contain “personal data” as defined by Article 4 of the European GDPR, but it does not contain your name, your email address, or any content from your files. All diagnostic data Microsoft collects during the use of Office applications and services is pseudonymized, as defined in ISO/IEC 19944:2017, section 8.3.3.

According to this Microsoft article (here) this is what the basic data is:

We use Basic diagnostic data to keep Windows devices up to date. Microsoft uses:

  • Basic error information to help determine whether problems your device is experiencing can be addressed by the update process.
  • Information about your device, its settings and capabilities, including applications and drivers installed on your device, to ascertain whether your device is ready for and compatible with the next operating system or app release and ready for update.
  • Logging information from the update process itself to understand how well your device’s updates are proceeding through the stages of downloading, pre-installation, post-installation, post-reboot, and setup.
  • Data about the performance of updates on all Windows devices to assess the success of an update’s deployment and to learn device characteristics (e.g., hardware, peripherals, settings, and applications) that are associated with the success or failure of an update.
  • Data about which devices have had upgrade failures and why to determine whether to offer the same upgrade again

 

However, if you want to block the transmission of this diagnostic data, on a per machine basis you can go into Windows 10 and change the default ‘enhanced’ to ‘basic’


 

To disable this on all machines, deploy the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DataCollection

Create a new a 32-bit DWORD value named AllowTelemetry and set it to 0

Windows 10 build 1511 and newer disable these two services:

Connected User Experiences and Telemetry
dmwappushsvc

Then restart the computer.

 

Now as it relates to Office, you need to go into the settings of the Diagnostic Viewer and enable the Office data viewer toggle as shown here:


For Office 365 ProPlus, Microsoft documents the diagnostic information sent to Microsoft (here)

You can manually turn this off on a per user basis as shown below, or you can disable it for all users using the config.office.com website also as shown below.

Office 365 ProPlus Manual Configuration

File Account > and under Account Privacy select Manage Settings.


 

Office 365 ProPlus Configuration for all machines (use config.office.com as shown below)

 


 

 

And for Windows 7, the July 9th 2019 security patch added telemetry. Disable or delete these scheduled tasks after the security patch installation but before rebooting the computer.

\Microsoft\Windows\Application Experience\ProgramDataUpdater
\Microsoft\Windows\Application Experience\Microsoft Compatibility Appraiser
\Microsoft\Windows\Application Experience\AitAgent

Reference: https://www.howtogeek.com/428265/windows-7s-july-2019-security-patch-includes-telemetry/

Unified Labeling in Azure Information Protection

Microsoft’s Rights Management Services (RMS) first debuted as a role in Windows Server 2003. It was then made available in Office 365 as Azure Rights Management, eliminating the hassle of hosting on-premises RMS server roles. When Microsoft acquired ‘Secure Islands’ in late 2015, that brought classification and labeling into the product, and so it was re-branded as Azure Information Protection. And then in 2018, support for both Mac OSX and Microsoft Windows required re-branding it into a more heterogenous name, as it is currently called Microsoft Information Protection.

 

The product is available in various license options:

  • Office E3 includes Rights Management for Office 365. This is the bare minimum RMS capabilities such as encrypting emails and documents, but it lacks customization and the latest bells and whistles.
  • EMS E3 includes Azure Information Protection, which adds the Secure Islands classification and labeling features, document tracking, revocation, and on-premises AIP Scanner functionality to scan and search for PII data in on-premises file shares and on-premises SharePoint.
  • EMS E5 adds the ‘Automatic Classification’ feature which will scan the content of a document and apply encryption, classification and labeling to a document. The AIP Scanner functionality is also extended to include encryption of data at rest that it finds in on-premises file shares and on-premises SharePoint.
  • M365 E5 which includes Windows 10 E5, is called “Microsoft Information Protection” because it extends protection to include data discovered on the Windows 10 endpoint. It can then prevent users from copying files to USB drives or unsanctioned locations. This feature also appears in the Office 365 Security and Compliance Center when configuring ‘Endpoint DLP’ as part of the DLP Policies. It leverages a combination of technologies including Windows Information Protection (WIP) and Mobile Application Management (MAM) policies on Windows 10.

 

 

On April 16th 2019, Microsoft announced (here) the general availability of the Unified Labeling Client. This is an MSI client software that can be distributed to Windows workstations that shows the labels found in the Security and Compliance Center’s Classification portal. Microsoft’s best practice is that if you have not yet deployed any of the legacy AIP labels, they suggestion you configure the new Unified Labels, distribute the new client (download here) (ending in *ul.exe) and be aware of the limitations that exist (here).


 

Join this free Microsoft webinar on Thursday, May 23rd at 7:00 AM PT to learn how to enable it, and the value that it brings to your organization: https://aka.ms/AIP-UL-Webinar

Defending against Evilginx2 in Office 365

[Updated 7/11/2019 – Azure AD now supports FIDO2 tokens for MFA, which also protect against EvilGinx2]

This is my second blog post in this series. In the first blog post (here) Aidan Holland (@thehappydinoa) demonstrated how EvilGinx2 can bypass Microsoft’s 2FA that is built into Office 365 (SMS Text or Mobile Authenticator), sometimes called “Always-On MFA.”

Kuba Gretzky (@mrgretzky) stated that it can defeat any form of 2FA!

“Be aware that: Every sign-in page, requiring the user to provide their password, with any form of 2FA implemented, can be phished using this technique!” https://breakdev.org/evilginx-2-next-generation-of-phishing-2fa-tokens

That’s a bold claim! Matt Soseman from Microsoft says, “always combine MFA with Conditional Access.” Matt is one of Microsoft’s top Cybersecurity experts, as he spoke on behalf of Microsoft at the RSA Security Conference in March 2019 (PDF HERE).

In this blog post, we are going to put both claims to the test. How does Microsoft’s Conditional Access compare against Evilginx2? We tested 13 of Microsoft’s defense capabilities and found 7 ways to defeat EvilGinx2. We also provide 4 recommendations for Microsoft to further improve security, and 5 recommendations for customers.

First, let’s define terms.

  • 2FA, or ‘two-factor authentication’ is most commonly something you know like a password, and then some other factor like an SMS text code or a token-based Authenticator mobile app.
  • MFA, or ‘multi-factor authentication’ can be multiple factors, not just two. For example, Microsoft’s conditional access allows you to go beyond user-authentication to perform machine authentication. You can check to see whether a computer is joined to the on-premises Active Directory domain, or whether it has a certificate issued from Active Directory Certificate Services (using Microsoft Cloud App Security Conditional Access App Control), or is originating from a range of IP addresses (aka IP-fencing). You can also check for the risk level of a user identity (using Azure Identity Protection) or the risk level of a machine (with Microsoft Defender ATP).

In our testing, we found that while EvilGinx2 is successful in bypassing the user-authentication forms of 2FA (yes, even the Microsoft Authenticator App!), and Azure Identity Protection.

EvilGinx2 was unsuccessful in bypassing the full MFA capabilities that Microsoft offers in Azure Conditional Access. This is available for customers who own the Azure AD Premium P1 license, which is also bundled in Enterprise Mobility Suite E3, and/or M365 E3.

According to Microsoft Corporate Vice President, Brad Anderson (@anderson), Microsoft’s EMS suite is currently owned by 100 million subscribers, which is currently 55% of the overall 180 million monthly active users in Office 365.

https://twitter.com/Anderson/status/1121516058345533440

This means there are 100M subscribers who can enable Azure AD Conditional Access to protect themselves from EvilGinx2 MFA bypass. This also means there are 80M subscribers who can only partially defend themselves against EvilGinx (using Client Access Rules). The client access rule only protects Exchange Online, not SharePoint Online, OneDrive, Dynamics, or any of the other Office 365 or Azure services.

How does EvilGinx2 Work?

In order to understand how Azure Conditional Access can block EvilGinx2, its important to understand how EvilGinx2 works. First, the attacker must purchase a domain name, like “office-mfa.com” and convince an end-user to click on that link. The attacker’s machine passes all traffic on to the actual Microsoft Office 365 sign-on page. Since all traffic is passed directly through, the end-user sees the *actual* Office 365 sign-in page. This means the attacker does not have to waste valuable time trying to make the page look identical. The authentication token is captured after the user performs user-based authentication (SMS or Authenticator App). The attacker can then import the cookie into their own browser to access Office 365. In our testing, the link was not blocked by MSFT EOP, Office ATP, Microsoft Defender ATP, or Windows Defender SmartScreen. However, we did find at least three methods that blocked EvilGinx2.

Figure 1 image credit – breakdev.org

The attacker’s EvilGinx2 server terminates the SSL session and it then re-transmits a new SSL session against login.microsoftonline.com. This avoids all SSL errors in the browser, since there is a valid ssl handshake to the attacker’s machine. This is an advantage for the hacker, but it turns out to be the Achilles heel because Azure Conditional Access can perform additional checks that will all block EvilGinx such as: IP address, Domain Join Membership, Compliance (via Intune UEM), or Certificate (via CASB).

Here is a screen shot showing Azure Conditional Access blocking EvilGinx2 because the attacker’s IP address does not match the policy.

Here is a screen shot showing that Azure Conditional Access blocks EvilGinx2 because the attacker’s proxy machine is not a domain-joined device

Here is a screen shot showing that Azure Conditional Access blocks EvilGinx2 because the attacker’s proxy machine is not meeting Intune compliance policy.

Here is a screen shot showing Microsoft Cloud App Security Conditional Access App Control successfully blocked the attacker from getting into Exchange Online because the attacker could not present a valid certificate.

Here is a screen shot showing new-clientaccessrule blocking EvilGinx2 from accessing the mailbox in Office 365

Another method that blocks EvilGinx is U2F (Universal 2nd Factor Authentication). The author of EvilGinx2 states (here) that U2F “leaves no room for error and is totally unphishable using Evilginx method…” and that “make your life easier and get a U2F device! This will greatly improve your accounts’ security.” [Update: On July 10th, Microsoft formally announced that Azure AD now supports FIDO2 in public preview (read announcement here).]

So here is a summary of all known/possible defenses in Microsoft’s security arsenal and how they measure up against EvilGinx2.

Defense EvilGinx2 Microsoft License Required Notes
Always-On MFA: “SMS” aka Text Messaging Bypass Successful Any O365 Plan The National Institute of Standards and Technology (NIST) updated guidance back in July of 2016 that government agencies should avoid SMS (NIST 800-63B).

There are several ways to bypass this form of 2FA (sim swapping, SS7, porting, etc).

The Payment Card Industry (PCI) follows the NIST guidance in its latest supplement on MFA issued in July 2017.

Always-On MFA: “Authenticator App” Bypass Successful Any O365 Plan Then authenticator app is much more secure than SMS/Text 2FA, however, because EvilGinx2 captures the authentication token issued, it successfully defeats even this more secure version of 2FA.
Azure Identity Protection Bypass Successful

[Evilginx2 bypassed Azure Identity Protection]

AAD P2 or (EMS E5, M365 E5, Identity & Threat Protection Bundle) We enabled the user risk policy and the sign-in risk policy to block logins with any user risk. We assume that since we had the captured token, Azure Identity Protection is not continuously checking the user identity (unlike the new-clientaccess rule which checks every attempt).
Azure Conditional Access: IP Fence Bypass Unsuccessful

[EvilGinx2 Blocked]

AAD P1 or one of the bundles (EMS E3+ or MS365 E3+) The reason why AAD Conditional Access can block EvilGinx is because the Attacker’s IP address is what is presented rather than the original user’s IP address.
Exchange Online Client Access Rule*
(new-clientaccessrule)
Bypass Unsuccessful against Exchange Online

[EvilGinx2 Blocked]

Any Exchange Online License Effective for protecting Exchange Online only.

(The hacker can get to office.com but then they get an error as soon as they click on Outlook)

Device Enrollment into Intune or Windows 10 Compliance Checking Bypass Unsuccessful

[EvilGinx2 Blocked]

Intune or EMS E3 or M365 E3 Since the attacker’s machine is not enrolled into Intune, it cannot pass a compliance check and it is therefore blocked.
Certificate Based Authentication
(Microsoft Cloud App Security Conditional Access App Control)
Bypass Unsuccessful

[EvilGinx2 Blocked]

AAD P1 + Microsoft Cloud App Security (or EMS E5) The attacker can get to office.com but then they get an error as soon as they access an application protected by an MCAS CAAP access policy)
Hybrid Domain Join Bypass Unsuccessful

[EvilGinx2 Blocked]

AAD P1 or EMS E3 or M365 E3 The reason why AAD Conditional Access can block EvilGinx is because the Attacker’s proxy device is presented rather than the original user’s device
Custom Branding Bypass Unsuccessful

[EvilGinx2 Blocked]

AAD P1 or EMS E3 or M365 E3 Note: in our testing, the ‘custom branding’ feature in AAD P1 caused EvilGinx2 to not render the sign-in page (this is a problem that they should be able to fix though, so I wouldn’t depend on this as a permanent countermeasure).
U2F (Ex: Yubico) Bypass Unsuccessful

[EvilGinx2 Blocked]

AAD P1 or EMS E3 or M365 E3 The author of EvilGinx has already tested and confirmed that U2F will successfully block because of the U2F origin binding implementation.
Windows Defender Smart Screen Smart Screen does not block an EvilGinx hyperlink

(due to zero reputation)

N/A – built into Internet Explorer since version 7, and Microsoft Edge and Windows 10 Creators Update, and available as an add-on for Chrome Smart Screen seems to only be effective against URLs that are in a block list. Since hyperlinks generated by EvilGinx have zero reputation, they are not blocked by Smart Screen.
Exchange Online Protection and/or Office 365 Advanced Threat Protection EOP and/or ATP does not block an EvilGinx hyperlink (due to zero reputation) Office 365 E5 or M365 E5 Since hyperlinks generated by EvilGinx have zero reputation, they are not blocked by ATP Safe Links. Safe Links records that the link was clicked on, which can be searched later using the URL trace feature.
Microsoft Advanced Threat Protection (prior to March 21st 2019 it was called Windows Defender ATP) MDATP (aka WDATP) does not block EvilGinx Windows 10 E5 or M365 E5 Microsoft ATP records that the link was clicked on but it does not block it.

Recommendations for Office 365 Customers

  1. If you are an Office 365 E3 subscriber, upgrade to Enterprise Mobility Suite and configure Azure AD Conditional Access for either (machine-authentication (domain-join checking, certificate checking) or IP address fencing) or (compliant device checking with Intune for Mobile Devices or Intune UEM for Windows 10). If you need assistance, find a qualified Microsoft Partner (here) and scroll down to the bottom.
  2. Consider implementing client access rules to protect Exchange Online. For an excellent overview of how client access rules work, watch this MSFT Ignite Video (here), fast-forward to 7:35 and watch until 15:55. Here is an example client access rule targeting a test account.
    new-ClientAccessRule -name “Allow InternalIP Only” -Action DenyAccess -ExceptAnyOfClientIPAddressesOrRanges [enter your public IP addresses here] -UsernameMatchesAnyOfPatterns *TestUserName
  3. Plan a U2F deployment, for example with Yubico. [This is now supported with Azure AD as of 7/10/2019].

    “With the YubiKey, user login is bound to the origin, meaning that only the real site can authenticate with the key. The authentication will fail on the fake site even if the user was fooled into thinking it was real. This greatly mitigates against the increasing volume and sophistication of phishing attacks and stops account takeovers.” Reference https://www.yubico.com/solutions/fido-u2f/

  4. Perform regular Security Awareness training to help users recognize suspicious URLs.
    Note: Microsoft’s Office 365 ATP has an exclusive feature called ‘Native Link Rendering’
    to show users the original hyperlink when they hover over it. No other advanced hyperlink scanning solution has this capability (I asked all the top vendors this question including ProofPoint, Mimecast, FireEye, Symantec and others). Native Link Rendering requires the Office 365 C2R (click-to-run) version, and not the volume-licensed MSI installer version of Office. Monthly Channel 1808 release (September 2018) or Semi-Annual Channel 1901 (which has not rolled out yet except to the Semi-Annual Targeted channel). See release notes (
    here).
  5. Harden the Office 365 tenant. A good place to start is my blog post ’20 Things to do before and after a phishing event in Office 365′. And we also offer a monthly service to continuously audit and harden Office 365, for more on that service click here.
    If you are investigating an incident and you believe a user’s token has been captured, you can invalidate a token with this AAD PowerShell cmdlet
    $date =get-date; Set-Msoluser -UserPrincipalName (UPN) -StsRefreshTokensValidFrom $date

Feedback for Microsoft:

  • Microsoft should consider improving Office ATP Safe Links and/or SmartScreen to take into consideration the age of a newly registered domain name. Some of Microsoft’s competitors can check the age of a domain name when determining hyperlink reputation.
  • Microsoft should consider developing features similar to new-clientaccessrule for the other services in Office 365 like SharePoint Online, OneDrive for Business, Teams, Dynamics
  • Azure Identity Protection could be improved to check every attempt, similar to new-clientaccesrule. We assume the fact that we had imported a captured token is why we did not get triggered by the User Risk policy or Sign-in risk policies (which were both set to ‘low and above’ with the block control).
  • Don’t give away which factor of authentication was the reason why the attacker could not sign-in. For example, in our testing the attacker is able to learn whether it was a domain join check or a compliance check that they failed. This is precisely what the PCI DSS takes issue with in their MFA guidance (here)

    Therefore we recommend that Microsoft change from Multi-Step to true Multi-Factor authentication. Today, any world-wide user can attempt to guess a username and password, only to then be blocked by a subsequent policy. This arms the attacker with too much information on which challenge failed.

-Joe Stocker, CEO

Patriot Consulting Technology Group, LLC

Our Mission “to empower our clients to manage cyber security risk by securely deploying Microsoft Cloud technology”

Office 365’s MFA is vulnerable to EvilGinx2

According to the latest Microsoft Security Intelligence Report, spear phishing remains the preferred attack method used by hackers. Microsoft detected a 250% increase in phishing messages between January and December 2018.

Figure 1 Page 21 of the Microsoft Security Intelligence Report Volume 24

Many organizations have deployed 2FA as a layer of defense to guard against phishing, so that if the user gives away the username and password, the attacker shouldn’t be able to logon to the user account. The purpose of this blog post is to raise awareness that Office 365 in particular is now vulnerable to “network session hijacking proxy theft” which allows an attacker to sign in regardless of the MFA solution (MSFT, Duo, RSA, SMS, etc). The authentication token is captured after the victim is tricked to going to a credential stealing website where they perform MFA through a proxy server. The token is then re-played by the attacker who can sign in as the user.

To see a demonstration of this, watch this Youtube video, https://www.youtube.com/watch?v=k4bq5A-icBw (Credit to @thehappydinoa)

Prior to this video, I haven’t been able to find any evidence of blog posts or videos demonstrating a successful bypass against Office 365’s 2FA capabilities. It’s worth noting that Office 365 is not unique – the same man-in-the-middle attack works against Google, LinkedIN, and other platforms as first demonstrated by Kevin Mitnick (KnowBe4) in May 2018 (original blog post (here). Since then other phishlets have been developed for Amazon, Github, Protonmail, Citrix, OKTA, Twitter, Instagram, Facebook, reddit, and consumer Outlook.com, and now Office 365.

The reason why this is important is because much of the security industry emphasizes MFA without raising awareness of this man-in-the-middle threat. For example, in my opinion one of the best presentations at the 2018 RSA conference was given by Booz | Allen | Hamilton which gave overwhelming evidence that 2FA would have stopped or reduced the impact of every one of the 159,700 total cyber incidents reported by the Online Threat Alliance in 2017. (Page 6, reference here). Now, the caveat has to be added that MFA would have stopped cyber incidents as long as victims were not tricked to going to proxy websites.

We have taken for granted that the very best anti-spam/anti-phish security solutions will not block 100% of the threats, and it is now time we accept the reality that MFA will not always prevent unauthorized authentication (much like how the SMS version of 2FA is no longer recommended or sufficient).

Roger Grimes of KnowBe4 gave a wildly popular presentation at the 2019 RSA Security Conference (requiring overflow seating) which listed 12 methods to bypass MFA (PDF download here). Some of these techniques require the attacker to invest a lot of time and sometimes money and risk (sim swapping) or be adept at social engineering (phone number porting). However, this all changed when Kuba Gretzky (@mrgretzky) released EvilGinx in 2017. Kuba showed how attackers can reduce their risk, cost, and effort through “network session hijacking proxy theft.” Grimes mentioned this technique among the 12 MFA bypass methods in his RSA presentation, and included a video showing how Kuba’s updated EvilGinx2, successfully bypasses the 2FA of Gmail and LinkedIN. At that time, there was no Office 365 phishlet available, but it was later added by @JamesCullum. 

In January at a Microsoft event, I asked Microsoft if Office 365 defended or detected network session hijacking proxy theft, specifically EvilGinx2. They stated that Office 365 would prevent this technique. [See part two of this blog series to see how]

Enter Aidan Holland (@thehappydinoa), who recently verified that EvilGinx2 can successfully bypass Office 365’s 2FA. Aidan also solved a vexing problem for Troy Hunt, who was trying to get a list of the Fortune 500 for his security research. Read about his solution to solve that problem here.

Aidan’s video is the first showing a successful bypass of Office 365 MFA:

https://www.youtube.com/watch?v=k4bq5A-icBw

(Credit to @thehappydinoa)

It’s worth noting that the phishing link generated by EvilGinx2 is not blocked by MSFT EOP, Office ATP, Microsoft Defender ATP, or Windows Defender SmartScreen.

In the next blog post (here), I will discuss ways to protect against EvilGinx2.

Analysis of DNS Recon of the Fortune 500 (Part 1 of 3)

In this three-part blog series, I will be writing about interesting trends amongst the Fortune 500 using public DNS reconnaissance posted in open source github repositories. This first post is focused on the email security providers used by the Fortune 500. The other posts will analyze adoption trends in DMARC and IdP Federation.

One of the favorite people I follow on twitter is Daniel Streefkerk (@dstreefkerk) from Sydney, Australia. Daniel tweeted on February 11th about a script he published to github (here) that performs DNS reconnaissance He posted a graph (here) of which email security providers were used by the top 250 Australian Companies.

 

Then a few days later he posted (here) how he updated the script to check for federation information (ex: Does the domain federate with OKTA, ADFS, Ping, OneLogin, etc?) and other interesting things like whether Office 365 was detected, the tenant name discovered (typically it is publicly listed in the DKIM DNS record).

I was curious how his findings in Australia compared to companies in the United States, but I couldn’t think of a simple way of finding the fortune 500 email domain names. Turns out, I was not alone. One of Daniel’s fellow Auzzies, Troy Hunt, a Microsoft Regional Director (a title similar to an MVP) recently asked a similar question (here) on March 31st:

Everyone seemed to have ideas but Troy seemed frustrated at one point that there wasn’t a simple list available somewhere. That’s when Aidan Holland (@thehappydinoa) came to the rescue and wrote an elegant 152-line python script (here) to gather about 455 of the 500 from a JSON query against hifld data. He then took that data and queried virus total, threat crowd, crt.sh, and finally validated it was a valid DNS domain for email by querying the MX record in DNS. All in 152 lines of Python. Impressive.

His JSON query the initial data set came from ARCGIS.COM with this code:

FORTUNE_500_JSON
=
“https://opendata.arcgis.com/datasets/a4d813c396934fc09d0b801a0c491852_0.geojson”


Aidan published the resulting list of 455 domain names (here). Then using PowerShell, we can pipe that into Daniel’s DNS recon script, to produce a report showing the email filtering systems used by the Fortune 500.

Get-Content fortune_455_emails.txt | .\Invoke-EmailRecon.ps1 | Export-Csv 455.csv


Raw Table Results:

Email Security Vendor

Count

Proofpoint

141

Self-Hosted

91

Microsoft Exchange Online Protection (EOP)

83

Other/Undetermined

59

Symantec.Cloud

36

Cisco Email Security (Formerly IronPort Cloud)

27

Google

11

Forcepoint (Formerly Websense)

4

Trend Micro

2

FireEye Email Security Cloud

1

 

The results indicate that most are using ProofPoint, Exchange Online Protection, or they are self-hosting their own service of some type.

Comparing the results to Australia, we can see that the US Market is consolidated to a few big players, whereas Australia is reasonably diversified. The significance of this is that malware should theoretically spread slower in Australia, because malware authors would have to work significantly harder to find vulnerabilities across multiple email security solutions if they wanted to infect the majority of the top 250 companies in Australia, whereas in the USA the malware authors just need to find a flaw in ProofPoint and Exchange Online Protection to infect 50% of America’s Fortune 500.

What surprised me was to see ProofPoint has a 6% penetration into the Australian market, compared to 28% in the United States (no surprise since ProofPoint HQ is in the USA).

These results could also be helpful for smaller or mid-size businesses who sometimes look at the decisions made by members of the Fortune 500 as a standard, ex: “good enough for them, good enough for me.”

Universities, think tanks, and research firms like Gartner and Forrester can now take periodic snapshots of this data to determine trends of email security vendors (or IdP federation vendors). Companies could use this data to find out which markets to expand into. And unfortunately Malware authors have most likely already figured out that targeting flaws in ProofPoint and Exchange Online will net them 50% of the Fortune 500.

In the next blog post, I will examine DMARC and IdP adoption trends.

Top 10 Fixes for troubleshooting free/busy between Exchange on-premises and Exchange Online in Office 365

Free/busy often fails to work out-of-the-box after configuring Hybrid Exchange with Office 365. Here are my top ten fixes:

 

  1. Set the sharing policy to match on-premises and cloud.

    First, Connect to Exchange Online Remote Powershell and run get-sharingpolicy

    Then connect to on-premises Exchange Management Shell and run get-sharing policy

    Then make the two match on both sides.

 

Set-SharingPolicy -Identity SharingPolicy01 -Domains ‘contoso.com: CalendarSharingFreeBusySimple’, ‘atlanta.contoso.com: CalendarSharingFreeBusyReviewer’, ‘beijing.contoso.com: CalendarSharingFreeBusyReviewer’

 

  1. Set the organization relationship domains to include all accepted domains on both on-premises and cloud (always requires an IISRESET for it to take effect)
    This script helps identify missing domains in an existing relationship:

     

    if ( (Get-OrganizationRelationship).DomainNames -contains (Get-Mailbox user).PrimarySmtpAddress.Domain) { write-host “The domain was found” -ForegroundColor Green } else { write-host (Get-Mailbox user).PrimarySmtpAddress.Domain “was not found” -ForegroundColor Yellow}

     

    $OrgRel = Get-OrganizationRelationship Contoso

    $OrgRel.DomainNames += “contoso.com”

    Set-OrganizationRelationship $OrgRel.Name -DomainName $OrgRel.DomainNames

     

     

    1. If the autodiscover DNS name is not published in external DNS, and if the client doesn’t want to do that, then manually configure TargetSharingEpr to use the published EWS path

      Get-OrganizationRelationship -Identity “O365 to On-premises – (GUID)” | Set-OrganizationRelationship -TargetSharingEpr https://mail.contoso.com/ews/exchange.asmx

    4) For ‘401 errors’ try disabling the IOC connector in Exchange 2013 to have oAuth fall back to dAuth


    5) Sometimes it’s necessary to set the on-premises EWS virtual directory “WSSecurityAuthentication” value back to defaults (some clients change this if they do load balanced CAS)
    (this is commonly a last resort)

    Need to change WSSecurityAuthentication to False for EWS Virtual directory.

        a.       Set-WebServicesVirtualDirectory “Exch CAS\ews*” –WSSecurityAuthentication $false

        b.      Need to Stop MSExchangeServicesAppPool.

        c.       Need to Start  MSExchangeServicesAppPool.

     

      Need to change WSSecurityAuthentication to True again for EWS Virtual Directory.

        a.       Set-WebServicesVirtualDirectory “Exch CAS\ews*” –WSSecurityAuthentication $True

        b.      Need to Stop MSExchangeServicesAppPool.

        c.       Need to Start  MSExchangeServicesAppPool.

     

      Need to change WSSecurityAuthentication to False for Autodiscover Virtual directory.

        a.       Set-AutodiscoverVirtualDirectory “Exch CAS\Auto*” –WSSecurityAuthentication $false

        b.      Stop MSExchangeAutodiscoverAppPool.

        c.       Start  MSExchangeAutodiscoverAppPool.

     

      Change WSSecurityAuthentication to True again for Autodiscover Virtual Directory.

        a.       Set-AutodiscoverVirtualDirectory “Exch CAS\Auto*” –WSSecurityAuthentication $true

        b.      Stop MSExchangeAutodiscoverAppPool.

        c.       Start  MSExchangeAutodiscoverAppPool.

     

    6) If the Exchange Server is behind a web proxy then it is usually necessary to configure InternetWebProxy Set-ExchangeServer <Server Name> -InternetWebProxy:http://<Proxy Address>:<Proxy Port>

     

    7)  Verify the availability address space and see required SMTP domain with access method.

        Get-AvailabilityAddressSpace (Run this on-prem)

     

    8) Try running diagnostic commands:
    You can also use the Test-FederationTrust (on prem only) and Test-OrganizationRelationship  (run this both on prem and in cloud too)

    And you can also use this website to run tests: https://www.testexchangeconnectivity.com/

    9) Make sure that the cloud user you are searching for has a valid (tenant).mail.onmicrosoft.com alias on their target mailbox (make sure Azure AD Connect is properly replicating that attribute, and/or, that the Exchange Address Policy is not blocking inheritance on that particular user/object).

     

    10) Run these commands to gather diagnostic information:

    Onpremises:

    Start-Transcript

    Get-FederationTrust | fl

    Get-FederatedOrganizationIdentifier | fl

    Get-OrganizationRelationship | fl

    Get-WebServicesVirtualDirectory | Export-Clixml C:\temp\WebVdir.xml

    Get-AutoDiscoverVirtualDirectory | Export-Clixml C:\temp\AutoDVdir.xml

    Get-RemoteMailbox bobc_sync | fl

    Get-Mailbox “on-premises John Doe User” | fl

    Test-FederationTrust -UserIdentity user@domain.com | fl

    Test-FederationTrustCertificate | fl

    Get-IntraOrganizationConnector | fl

    Stop-Transcript

     

    Online:

    Start-Transcript

    Get-FederationTrust | fl

    Get-FederatedOrganizationIdentifier | fl

    Get-OrganizationRelationship | fl

    Get-MailUser “on-premises John Doe User” | fl

    Get-Mailbox “Cloud user” | fl

    Get-IntraOrganizationConnector | fl

    get-OrganizationRelationship | Test-OrganizationRelationship -UserIdentity “cloud user”

    Stop-Transcript

     

     

     

    And when all else fails I reference these two blog articles:

    https://blogs.technet.microsoft.com/exchange/2018/02/06/demystifying-hybrid-freebusy-what-are-the-moving-parts/

    and

    https://blogs.technet.microsoft.com/exchange/2018/03/02/demystifying-hybrid-freebusy-finding-errors-and-troubleshooting/

How to fix Exchange Online Hybrid Outbound Connector 454 4.7.5 Certificate Validation Failure

While recently helping a client setup an Exchange Hybrid, the cloud to on-premises mail flow was failing validation due to 454 4.7.5 Certificate Validation Failure.

The next step was to verify that the TlsCertificateName value was properly set on the send and receive connectors to match the certificate name, following these articles:

https://blogs.technet.microsoft.com/lalitbisht/2017/06/03/mailflow-issue-from-exchange-on-prem-to-office-365/

https://practical365.com/exchange-server/configuring-the-tls-certificate-name-for-exchange-server-receive-connectors/

In this case, the TlsCertificateName was already set correctly to match the certificate name (the Hybrid Exchange Wizard does a good job at setting that correctly).

The next step was to enable Verbose logging on the on-premises receive connector so that we can get a better look at the error.

To save time, I restarted the “Microsoft Exchange Frontend Transport” service so that the logging would take effect sooner.

Then navigating to the log directory can be a bit tricky:

C:\Program Files\Microsoft\Exchange Server\v15\TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive

Opening up the file revealed a very helpful bit of information! The SSL Certificate that Microsoft Office 365 is presenting to the Exchange server for the TLS encrypted email is not a trusted root. How can this be?

 

To cut to the chase, the root cause was that the server had not had windows updates run in a LONG time and therefore was really far behind in its root certificates.

The least disruptive solution was to download the Office certificate chains from Microsoft (here) and install them on the on-premises Exchange Server. Then after restarting the “Microsoft Exchange Frontend Transport” service and waiting a few minutes, the validation was successful.

Passwordless phone sign-in with the Microsoft Authenticator app – not compatible with conditional access require approved client app

This blog post details the effort to enable passwordless phone sign-in to Azure Active Directory using the Microsoft Authenticator App. Last week Microsoft announced this capability on September 26th at the Ignite Conference.

In my environment, I had to first install the Azure AD PowerShell preview module:

Install-Module -Name AzureADPreview -RequiredVersion 2.0.0.114

The first error I got reminded me that I had to run it in an elevated PowerShell window.

The second error I received informed me that there were already existing commands available:

“PackageManagement\Install-Package : The following commands are already available on this system: [Insert a TON of commands] followed by “This module ‘AzureADPreview’ may override the existing commands. If you still want to install this module ‘AzureADPreview’,use -AllowClobber parameter.”

In my case, it errored out because I had previously installed the production Azure AD PowerShell module, so I added the -AllowClobber to the end like this:

Install-Module -Name AzureADPreview -RequiredVersion 2.0.0.114 -AllowClobber

The next thing to do is to connect to Azure AD:

Connect-AzureAD

Then run this command:

New-AzureADPolicy -Type AuthenticatorAppSignInPolicy -Definition ‘{“AuthenticatorAppSignInPolicy”:{“Enabled”:true}}’ -isOrganizationDefault $true -DisplayName AuthenticatorAppSignIn

You can now run a get-AzureADPolicy to see the same information above. This would be a way to check to see if another tenant admin already beat you to the task =)

 

End User Steps

 

End-users need to enable sign-in on their Microsoft Authenticator App as described here: https://docs.microsoft.com/en-us/azure/active-directory/user-help/microsoft-authenticator-app-phone-signin-faq

 

I immediately hit a roadblock where the Authenticator App was ironically blocked by our Conditional Access Policy which requires only approved client apps.

 

Very strange that Microsoft’s own Authenticator app is not an approved client app.

Another tell-tale sign that something was wrong was I had an exclamation point next to the account inside the Authenticator app.

So I then excluded myself from that policy and continued setup. I had to select an option in the Authenticator app to update phone sign-in.

 

This worked and then I was able to test the passwordless sign-in successfully. The web page will give you a number, and then you go back into the authenticator app and you select the number from three options.

If you are wondering why 77 is not in the list of three options below, it’s because I didn’t time the screen shot correctly =)

Therefore, I think Microsoft should update the known issues list to include this problem that existing Conditional Access Policies may block the passwordless sign in from working properly.

I also added a UserVoice request to have Microsoft Authenticator added to the list of approved client apps. Kind of funny that this isn’t approved already, but hey, please vote!

https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/35605771-add-microsoft-authenticator-to-approved-client-app

So unfortunately, because our organization relies upon the ‘require approved client app’ to block unsavory apps, we needed to roll back this change.

Rollback Tenant

Get-AzureADPolicy | Remove-AzureADPolicy

Rollback all enrolled Authenticator apps

I discovered that rolling back the tenant was not enough. I also had to remove my O365 account from inside the Authenticator app on my mobile device. I assume when my account was upgraded to Phone sign-in, it must have altered it beyond repair. So I went into the Authenticator App accounts and removed the account, and then re-enrolled it by going to http://aka.ms/MFASetup. Finally, I was able to get back in.

So now that I have tasted how cool passwordless sign-in, I would really like to use it, but will need to wait until it is compatible with the ‘require approved app’ conditional access feature.

References:

https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-authentication-phone-sign-in

 

Azure Conditional Access and Azure AD Connect Service Account

If you deploy an Azure Conditional Access policy to require all Windows PC’s to be domain joined, you may find that Azure AD Connect no longer synchronizes.

And during an upgrade to the latest version of Azure AD Connect, you may be prompted with the error message “System.InvalidOperationException: Showing a modal dialog box or form when the application is not running in UserInteractive mode is not a valid operation.”

To resolve this, modify the conditional access policy to exclude the Azure AD Connect Service Account, which can be found by searching for “On-premises directory synchronization service account”

Then create a second conditional access policy that is targeted this same on-prem account with a condition exclusion for all trusted locations, and a block rule for all other access. This effectively creates an IP-Fence that prevents this service account from logging in from anything other than the trusted location.

In Preview: Privileged Access Management for Office 365

Privileged Access Management (PAM) for O365 is a way to restrict access to Office 365 administrative functions by requiring a separate person such as a manager (or someone designated the approver role) to grant access to administrative functions.

PAM is currently a PowerShell-only feature (no graphical user interface… yet) and is limited to Exchange Online at this time. Other workloads such as SharePoint Online are planned in the future. Therefore, it is more or less a proof of concept at this time, because PowerShell is not a skill that most entry-level helpdesk have acquired.

It’s a step in the right direction for sure, as it provides more fine-grained access management than Azure Privileged Identity Management (AzPIM), which gives access to an entire role for a period of time.

Where PAM differs, is that it grants access to perform certain commands only, rather than opening up the entire privileged role to someone.

It’s a nice compliment to AzPIM, but to avoid confusion I feel this should really be part of AzPIM as opposed to a separate O365 E5 feature. Microsoft should be cautious to avoid the appearance of having EMS E5 products compete against O365 E5 products. Case in point, it’s challenging for customers to understand the difference between O365 E5 Cloud App Security versus EMS E5 Cloud App Security. The same product is sold with different feature sets, but why add this confusion? In my opinion, all security elements should be bundled in EMS, and make O365 a pure productivity package. 

The other challenge with O365 PAM, and Azure PIM, is that they do not integrate with the on-premises Windows Server 2016 PAM. So effectively, a customer would have to implement three separate solutions that don’t integrate with each other. This may be a product of Agile software development than anything else. If Microsoft is consistent with what they have done with other products, we should expect to see “Microsoft PAM” which will integrate or replace all three O365 PAM, Azure PIM, and Windows PAM. At that point it will be able to compete strongly against Lieberman (now Bomgar) and/or CyberArk.

Try Office 365 PAM out here: https://docs.microsoft.com/en-us/Office365/Enterprise/privileged-access-management-in-office-365