But how can we make sure we have not been exploited by that vulnerability? Microsoft has released a script for local Exchange installations as well for Exchange Online/ Microsoft 365.

This blog post shows how to use the Script to identify potential malicious mails in M365.

First we need to start Powershell as administrator. After that we install the AzureAD module:

PS C:\Users\Administrator> Install-Module AzureAD

Powershell will then ask if the module should be installed from an external source. Please select Yes (Y) here.

Next, we need to install the Exchange Online module:

PS C:\Users\Administrator> Install-Module -Name ExchangeOnlineManagement -RequiredVersion 3.1.0

Powershell will then ask again if the module should be installed from an external source. Please select Yes (Y) again.

The script used in the following step can be downloaded from here.

Now we need to create an AzureAD application, which is needed to check the mailboxes:

PS C:\Users\Administrator\Downloads> .\CVE-2023-23397.ps1 -CreateAzureApplication

Depending on the Powershell configuration, it may be necessary to confirm again that the script may be executed. You can either chose (M) or (A). I recommend chosing M.

A new window will open to log in to M365 as a global administrator or application administrator.

If your output is similar to the following creating the helper application has worked:

CVE-2023-23397 script version 23.03.15.2119

Prompting user for authentication, please minimize this window if you do not see an authorization prompt as it may be in the background

Adding user adminuser@yourtenant.com as owner of CVE-2023-23397Application

Setting Azure AD Permissions

Assigning Necessary Azure AD Service Roles
Application created with required permissions. Client ID: xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

After this step we now can start the investigation. We need to connect to Exchange Online first:

PS C:\Users\Administrator\Downloads> Connect-ExchangeOnline

You might need to re-authenticate at this point to M365. (I did not need to log in again at this step)

And then we can start the Powershell script to search for malicious files (If you selected (M) when running the script for the first time, you must confirm execution again now):

PS C:\Users\Administrator\Downloads> Get-Mailbox -ResultSize Unlimited | .\CVE-2023-23397.ps1 -Environment "Online"

At this point it is mandatory to authenticate again. Output should be similar to the following:

CVE-2023-23397 script version 23.03.15.2119
Trying to find Microsoft.Exchange.WebServices.dll in the script folder
Microsoft.Exchange.WebServices.dll wasn't found - attempting to download it from the internet

Prompting user for authentication, please minimize this window if you do not see an authorization prompt as it may be in the background

Waiting 60 seconds for app credentials to register..

Continuing...
Scanning 1 of 16 mailboxes (currently: mailbox1@yourtenant.com)
Scanning 2 of 16 mailboxes (currently: mailbox2@yourtenant.com)
Scanning 3 of 16 mailboxes (currently: mailbox3@yourtenant.com)
Scanning 4 of 16 mailboxes (currently: mailbox4@yourtenant.com)
Scanning 5 of 16 mailboxes (currently: mailbox5@yourtenant.com)
[...]
Scanning 16 of 16 mailboxes (currently: mailbox16@yourtenant.com)
No vulnerable item found

Do you have feedback regarding the script? Please email ExToolsFeedback@microsoft.com.

I hope you will see the same output as I do. The script also supports deleting affected files. For more information please look at Microsofts script documentation.

After checking the mailboxes, we no longer need the AzureAD Helper Application. To delete the application just run the following command:

PS C:\Users\Administrator\Downloads> .\CVE-2023-23397.ps1 -DeleteAzureApplication

You have probably already guessed: First you have to allow the script again and thereafter you have to authenticate to Microsoft 365 a last time

I hope the explanation helped you to check your tenants. Feel free to let me know if it worked or if you had any problems with it.

Der Beitrag Howto check your M365/Exchange Online environment for messages exploiting CVE-2023-23397 erschien zuerst auf MEB-IT | Blog.

The first step will be to uninstall the Azure AD Sync tool. Uninstall the tool from the server/machine its running on.

In the next step we need to connect to Azure AD via Powershell. This does not work with Linux, that’s why we need a Windows machine. Open Powershell as admin and type the following to install the required cmdlets:

Install-Module -Name MSonline

If you are prompted chose “Y” for yes to install the module.

In the next step we are connecting to Azure AD:

Connect-MsolService

Type in your credentials when the prompt opens and hit Enter.

Now we are going to check whether Azure AD Sync is enabled:

(Get-MsolCompanyInformation).DirectorySynchronizationEnabled

If you receive “True” as answer, Azure AD sync is enabled. If you receive “False” it’s disabled. In the case of “False” you don’t need to do anything further!

Now we are going to disable the synchronization:

Set-MsolDirSyncEnabled -EnableDirSync $false

If we now check the Azure AD Sync status it should show “False”:

(Get-MsolCompanyInformation).DirectorySynchronizationEnabled

Der Beitrag Howto disable Azure AD Sync after migration erschien zuerst auf MEB-IT | Blog.

As the first step we need to connect to our M365 Powershell. The last paragraph in this article describes how to do this.

The following command shows a comprehensive list of DKIM related information for domain “domain.com”:

Get-DkimSigningConfig -Identity domain.com | Format-List

If we just want to check the DKIM status of our domains we can use the following command:

Get-DkimSigningConfig

My example shows that DKIM is enabled for our Microsoft tenant domain but isn’t for our primary sending domain. Before we are able to enable DKIM for our sending domain we need to setup DNS records for verification:

Get-DkimSigningConfig -Identity domain.com | Format-List Selector1CNAME, Selector2CNAME

Now we need to set the CNAME records in our dns. Copy selector1 and create a new CNAME entry in your DNS settings. Repeat for selector2 (Destination is just an example, use the output generated in the previous step):

Host: selector1._domainkey
Destination: selector1-domain-com._domainkey.youronmicrosoftdomain.onmicrosoft.com

Host: selector2._domainkey
Destination: selector2-domain-com._domainkey.youronmicrosoftdomain.onmicrosoft.com

At this point we need to wait until the dns records have been propagated. Wait at least 10 – 15 minutes until you proceed. Chose on of the options below:

Option 1: Via Powershell

Open a Powershell session to your M365 tenant and type the following command:

Set-DkimSigningConfig -Identity domain.com -Enabled $true

Option 2: Via Security Admin center

• Login to M365 Admin center (https://admin.microsoft.com)
• Go to Security Admin center
• Go to Threat management -> Policy
• Click on DKIM
• Click on your domain
• Turn the disabled slider to enabled and save

Option 3: Via old Exchange Admin center

• Login to M365 Admin center (https://admin.microsoft.com)
• Go to Exchange Admin center
• Go to Classic Exchange admin center
• Go to Protection -> dkim
• Double click your sending domain and click on Enable

If you encounter an error in on of the above steps make sure that your DNS records are set properly. You can check the entries with the following command for Linux:

dig selector1._domainkey.domain.com
dig selector2._domainkey.domain.com

The output should include the CNAME entry for selector1/selector2 you created in your domain name settings. If you are using Windows you can use the following cmd command:

nslookup -q=CNAME selector1._domainkey.domain.com
nslookup -q=CNAME selector2._domainkey.domain.com

Both selectors must be correctly set before Microsoft allows you to enable DKIM for your domain. If both entries are correct wait another 15 -30 minutes and try to enable DKIM via one of the above options again.

Der Beitrag Howto enable DKIM in Microsoft 365 erschien zuerst auf MEB-IT | Blog.

First we should check the actual database server the mailbox is located on:

Get-MailboxLocation -Identity user@domain.com

As you can see in the above image, the field “DatabaseLocation” shows the hostname of our database server. We are now going to set up a move request for this mailbox. In Microsoft 365 / Exchange Online we are not able to chose the desired server we want to move our mailbox to. Microsoft will move the mailbox to a random, different server:

New-MoveRequest -Identity user@domain.com

Once we created the move request we need to wait for the moving provess to finish. We are able to check the status with the following command:

Get-MoveRequestStatistics -Identity user@domain.com

It took this 18GB mailbox about1.5 hours to finish. That depends most likely on the usage of source and destination server. After this operation has finished the user should restart their Outlook.

Der Beitrag Move a M365 Mailbox to another database server erschien zuerst auf MEB-IT | Blog.

Linux derivates officially supported for Powershell 7.1:

• Ubuntu 16.04/18.04/20.04
• Ubuntu 19.10 (via snap-packages)
• Debian 9/10
• CentOS/RHEL 7/8
• Fedora 30
• Alpine (from 3.11)

Installation example (Ubuntu 20.04)

You can directly install Powershell via repository:

# Update the list of packages
sudo apt-get update
# Install pre-requisite packages.
sudo apt-get install -y wget apt-transport-https software-properties-common
# Download the Microsoft repository GPG keys
wget -q https://packages.microsoft.com/config/ubuntu/20.04/packages-microsoft-prod.deb
# Register the Microsoft repository GPG keys
sudo dpkg -i packages-microsoft-prod.deb
# Update the list of products
sudo apt-get update
# Enable the "universe" repositories
sudo add-apt-repository universe
# Install PowerShell
sudo apt-get install -y powershell
# Start PowerShell
pwsh

Connect to Office 365 Powershell

After Powershell has been installed, it’s very easy to connect to Office 365. Open the Powershell terminal and type the following (First step will ask for O365 admin credentials)

$O365Credential = Get-Credential

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $O365Credential -Authentication Basic -AllowRedirection

Import-PSSession -Session $Session

The last step takes a few seconds until the Office 365 session has been imported. Afterwards you can run the available Powershell cmdlets.

Der Beitrag Powershell on Linux erschien zuerst auf MEB-IT | Blog.