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 PatriotConsultingTech.com

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 (microsoft.com)

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 Eicar.com sample malware file on a USB Drive.

image

image

image

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

image

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

image

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

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:




Server SCEP or MAA MMA MDAV
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 (securitycenter.windows.com).

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.

image

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 (securitycenter.windows.com) > 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 (securitycenter.windows.com) > 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.

References

*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 http://aka.ms/defenderios

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:

clip_image001

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.

clip_image001[4]

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.

clip_image001[6]

Here is an example of the block page:

clip_image001[8]

Then Administrators can view these events in the Defender security portal (securitycenter.windows.com)

image

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.

Switch your Public DNS zone to Azure DNS

Recently we experienced an issue with Cloudflare DNS. I opened a support ticket but they were unable to explain why some locations around the world were unable to resolve our DNS MX records.

image

This was causing non-deliverable email problems so we decided to switch to Azure DNS.

Step 1 – Export the DNS Zone from Cloudflare (Advanced –> Export)

image

Step 2 – Create the DNS Zone in Azure

I prefer using the Web Interface (here)

Step 3 – Import the zone file into Azure DNS

Install Azure CLI from (here)

Launch PowerShell
#Login to Azure CLI
az login
#List your Subscriptions
az account list
#Select a Subscription
az account set –subscription “My Demos”
#Make sure you see the DNS Zone that you created in step 2
az network dns zone list
#Import Zone from file (Documentation is here)

az network dns zone import -g MyResourceGroup -n mysite.com -f zone.txt

PowerShell Alternative to Azure CLI

Don’t like Azure CLI? You can also manage your zone with the regular PowerShell module:
Install-Module -Name AzureRM.Dns -Force
Install-Module -Name AzureRM.Network -Force
Connect-AzureRmAccount
Get-AzureRmSubscription
Select-AzureRmSubscription -SubscriptionName “My Demos”
Get-AzureRmDnsZone

Use PowerShell to Connect to Exchange Online unattended in a Scheduled Task

If you have MFA enabled, how do you connect to Exchange Online in an unattended script, like a Scheduled Task? Some people may have embedded a password into their scripts, but that will stop working in mid 2021 when Microsoft retires basic authentication in Office 365.

Microsoft has a preview version of Exchange Online v2 PowerShell that allows you to use a Certificate to authenticate.

Why Certificates? Because you don’t want an MFA push notification on your iPhone every morning at 1:00 AM, right?

Recommendation: Review to see if you have any automated scripts connecting to Exchange Online (typically scheduled tasks).

How? Follow the steps below to use certificates to connect to Exchange Online PowerShell

Prerequisites

Install-Module ExchangeOnlineManagement -RequiredVersion 2.0.3-Preview

Or if you already have a previous version of the module installed:

Update-Module ExchangeOnlineManagement -RequiredVersion 2.0.3-Preview

Note: If you get an error “A parameter cannot be found that matches parameter name ‘AllowPrerelease’” then run this command
Install-Module PowershellGet -Force (then close and re-open PowerShell)

Instructions

  1. Register an app in Azure AD (here).
    (The app is the entry point to Exchange Online PowerShell because it creates a service account called a service principal to perform administrative actions)
    image
  2. Click API Permissions on left navigation > Add a permission
    image
  3. Scroll to the bottom of the Request API permissions pane and click on Exchange under the Supported legacy APIs section.
    image
  4. Click on Application permissions
    image

  5. Expand the Exchange entry, and select the Exchange.ManageAsApp permission.
    Click the
    Add permissions button below to complete the operation.
    image
  6. Click “Grant Admin consent for your tenant”
    image
  7. Create a Role to assign to the App (Thanks to Tony Redmond for this tip)

$ExoAppSp = (Get-AzureADServicePrincipal -Filter “DisplayName eq ‘Exchange Online Scripting'”).ObjectId

$ExoRoleId = (Get-AzureADDirectoryRole | ? {$_.DisplayName -eq “Exchange Service Administrator”}).ObjectId

Add-AzureADDirectoryRoleMember -ObjectId $ExoRoleId -RefObjectId $ExoAppSp

  1. Create a self-signed X.509 certificate that will be used for authentication
    New-SelfSignedCertificate -Subject “Exo Background Process” -CertStoreLocation “cert:\CurrentUser\My” -KeySpec KeyExchange -FriendlyName “For EXO V2 Background Jobs”
  2. Open MMC, add Certificates, Find the new Cert, and Export it *without* the private key, as a .CER file.
    image
  3. Upload this file to the app you registered in the Azure Portal
    image

After adding the certificate, we need three items before we can finally connect unattended with PowerShell

  • The AppId of the application you created.
    Get-AzureADApplication -Filter “DisplayName eq ‘Exchange Online Scripting'”
  • The thumbprint of the certificate loaded into the app
    Get-ChildItem -path ‘Cert:\*’ -Recurse |where {$_.Subject -like ‘*EXO*’}
  • The service domain for your tenant (like tenant.onmicrosoft.com).

With these values, you can connect to Exchange Online using certificate-based authentication with a command like:
Connect-ExchangeOnline -CertificateThumbprint ” 960BD967A9287CE83DF4138805B5CE2FCA4C9B8B” -AppId “b83c46c6-044e-40e5-929c-634f80045a11” -ShowBanner:$false -Organization tenant.onmicrosoft.com

References

· Microsoft Documentation

· Vasil Michev

· Tony Redmond: Office 365 IT Pros

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”

clip_image002

Sysinternals will show “App Container” 

clip_image004

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

image

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?

Defending against Pass-the-PRT

The Azure AD Primary Refresh Token (PRT) can be extracted using ROADtools, written by security researcher Dirk-jan Mollema and recently weaponized into Mimikatz by Benjamin Delpy.

With local Administrator privileges it becomes possible to extract the PRT and the required cryptographic material to sign in on any Azure AD connected resource with the account to which the PRT was issued. The PRT is valid for 14 days and can be used on any device in this time-frame. Any MFA claims that were assigned to the PRT remain valid as well.

It’s important to understand exactly how this attack works so that you can test your defenses against it. You should never assume that your defenses are adequate. Just like a backup is not good unless it is restored, your defenses are not good unless you test them frequently and thoroughly.

A PRT is only issued to native apps (like the full Outlook client) on Azure AD Registered, Azure AD Joined, or Hybrid Azure AD joined devices. A browser session on a workgroup machine will not receive a PRT. To learn more about how PRT’s are issued, see this article: https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token

The attacker runs a few mimikatz commands:

privilege:debug
sekurlsa::cloudap

cloudap1

The PRT can then be imported into Chrome as a cookie:

image

And this allows the attacker to sign in as the user, even if their device is not Intune compliant or Hybrid Azure AD joined.

Defending against Pass-the-PRT

There are ~15 Attack Surface Reduction Rules (ASR) in Windows 10. The following rule can be enabled in Audit or Block mode. We strongly recommend Audit mode first because Block mode may block legitimate processes that you will need to exclude before deploying this in production. On a single test machine you can run this command for audit mode:

Add-MpPreference -AttackSurfaceReductionRules_Ids 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 -AttackSurfaceReductionRules_Actions AuditMode

And this command for block mode:

Add-MpPreference -AttackSurfaceReductionRules_Ids 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 -AttackSurfaceReductionRules_Actions Enabled

And when this ASR rule is enabled, we can see that Mimikatz is unable to dump the PRT

image

Normally this should get logged as Event 1121 (Block) or 1122 (Audit) in the Event Viewer: Microsoft-Windows-Windows Defender/Operational

Or if you have Microsoft Defender ATP then in the Timeline view you can filter on ASR Events:

image

Recommendations

1. Do not grant users local administrator privileges

2. Enable Tamper Protection in Windows Defender. It is more difficult for Mimikatz to run when Defender AV is running.

3. Enable Attack Surface Reduction Rules (ASR)  to block access to LSASS.exe

Switch from ADFS to Azure AD

A surprising number of clients are still operating complex ADFS farms.

ADFS Complexity 

Here are 8 reasons to switch to Azure AD.

1. ADFS has a greater surface attack area than Azure AD. Example: NTLM Brute-Force (CVE-2019-1126).

2. ADFS can have multiple single points of failure unless designed properly

3. ADFS requires certificate maintenance – resulting in planned downtime

4. ADFS requires lots of IT overhead (Backups, Monitoring, OS Upgrades, etc)

5. Azure AD Conditional Access offers better security controls than ADFS Claims

6. Azure AD is lightweight and less complex to administer (No Claims Rules)

7. Azure AD more closely aligns to NIST 800-63b (Scan for breached passwords)

8. Azure AD has a better feature roadmap

It’s easy to switch from ADFS to Azure AD. For example, this one PowerShell command can migrate Office 365 from ADFS to Cloud in less than 5 minutes. Set-MsolDomainAuthentication -DomainName mydomain.com -Authentication Managed

You can also do a staged rollout of smaller groups at a time rather than a big bang cutover using (the first security group is limited to 200 users). Learn more about staged rollout (here).

Note: That’s the core command that moves the trust from ADFS to Azure AD. There are more planning steps involved like making sure you have enabled password hash sync. Learn more planning steps (here).

Here are 5 tips for moving other apps from ADFS to Azure AD

  1. Use the new ADFS Application activity report (preview) or the ADFS to Azure AD app migration tool to analyze your current apps. This tool will quickly identify which apps can be migrated seamlessly and which require remediation (see figure one).
  2. Acquire deployment guides for the relevant apps. Many are published on the Microsoft app gallery, but if not, you can open a ticket through the third-party vendor who developed the app.
  3. Allocate appropriate time and resources to the high-touch apps.
  4. Migrate the apps that are ready to go for quick wins.
  5. Identify a test environment or plan a maintenance window to avoid moving large servicing app at peak usage.

Learn more here:

https://techcommunity.microsoft.com/t5/azure-active-directory-identity/five-tips-to-improve-the-migration-process-to-azure-active/ba-p/445364

What is Double Key Encryption (DKE)?

Today Microsoft announced the public preview of Double Key Encryption (DKE).

What does “Double Key” mean? It’s similar to a missile launch where two people must turn their key at the same time. In the case of encryption, it is the combination of two keys held by separate parties that encrypt or decrypt data.

DKE

Or to quote Microsoft:

“Double Key Encryption enables you to protect your highly sensitive data while keeping full control of your encryption key. It uses two keys to protect your data—one key in your control, and a second key is stored securely in Microsoft Azure. Viewing data protected with Double Key Encryption requires access to both keys. Since Microsoft can access only one of these keys, your protected data remains inaccessible to Microsoft, ensuring that you have full control over its privacy and security.”

Your Client Key is hosted outside of Microsoft (wherever you want) via a web service that you are responsible for hosting. If your web service goes down (intentionally or unintentionally) then no new data can be encrypted or decrypted.

This is similar to its predecessor, Hold-Your-Own-Key (HYOK) which I assume DKE will eventually replace at some point in the future. Except there is one big advantage: Unlike HYOK, DKE does not depend upon on-premises Active Directory Rights Management Services (AD RMS). So it is a simpler configuration.

Is DKE right for me? Most likely not. It’s intended for some super rare scenarios that very few clients have. There are serious productivity limitations to DKE that are nearly identical to HYOK, where many features inside Office 365 and other services will not function such as SharePoint Search, eDiscovery Search, Data Loss Prevention, Transport Rules, Exchange ActiveSync, Journaling, Malware scanning, Archiving Solutions and any other services that needs to read data such as 3rd party document management systems.

Therefore customers should carefully evaluate all key options before proceeding with DKE (see table below).

What if I lose my key? Your data is inaccessible, and there is no ‘back door’ key like the ‘Availability Key’ feature in BYOK that allows Microsoft to decrypt data if you lose your BYOK key.

Encryption Key Comparison

HYOK

(Hold-Your-Own-Key)

Double-Key Encryption (NEW) BYOK
(Bring-Your-Own-Key)
Microsoft

Managed Key

Can Microsoft Read the Encrypted Data? No No Yes Yes
AD RMS Required? Yes No No No
100%Cloud Hosted No No Yes Yes
On-Prem or Cloud
DMZ Req?
No Yes No No
On-Prem
HSM Req?
Yes Yes Yes No
ActiveSync Support No No No No
Exchange On-Premises IRM No No Yes Yes
Outlook Mobile No No Yes Yes
OWA No No Yes Yes
Office Mobile

(Word/Excel/PPT)

Yes (Consume Only) Yes (Consume Only) Yes Yes
Mac OSX Yes (Consume Only) Yes (Consume Only) Yes Yes
SharePoint Search No No Yes Yes
Key Strength RSA 2048-bit (Key Exchange)

AES 128 (Wrapping)

SHA 256 (Signing)

(FIPS 140-2)

RSA 2048-bit (Key Exchange)

AES 128 (Wrapping)

SHA 256 (Signing)

(FIPS 140-2)

RSA 2048-bit (Key Exchange)

AES 128 (Wrapping)

SHA 256 (Signing)

(FIPS 140-2)

RSA 2048-bit (Key Exchange)

AES 128 (Wrapping)

SHA 256 (Signing)

(FIPS 140-2)

External Collaboration No No Yes Yes
Office Client Support Office 2013 + Office Insider* Office 2013 + Office 2010 +
Auditing Yes Yes Yes Yes

Office Insider is required at the time of this writing (July 2020) but eventually it will roll out to Office versions in mainstream support.

Initially at the time of this writing, the AIP Unified Labeling Client is required to encrypt/decrypt content. It will eventually be available natively in the Office Ribbon.

Additional Resources

Blog Post: https://aka.ms/DKEpreview
Deployment Docs: https://aka.ms/DKEpreviewdocs
Github Repo: https://aka.ms/DKErepo
Update [10/22/2020] Host DKE on IIS, using an on-premises server – Microsoft Tech Community