A typical tactic after a business email compromise event is the creation of email forwarding rules using any one, or more, of these methods by an attacker:
– Use rules in Outlook Web App to automatically forward messages to another account
– Client rules
It is therefore good practice to regularly check and verify the email forwarding rules inside your Microsoft 365 environment.
I have created a free PowerShell script exactly for this purpose, which you can find here:
Office365/o365-exo-fwd-chk.ps1 at master · directorcia/Office365 · GitHub
and the video:
will provide a walk through of its execution.
Once you have set up your PowerShell environment the next thing is to use it to connect to Microsoft 365 services like Exchange Online and Teams.
I have created several free automation scripts at:
to make that process easy.
In this video, I’ll walk you through the steps of using what I have created to make it simple to connect to any Microsoft 365 service using PowerShell quickly and easily.
Here is a direct link to the video:
Keeping all your PowerShell modules up to date for Microsoft 365 is easy using the process in this video along with the free script I provide here:
Simply use the script, with elevated privileges, and you can automatically update all the modules. If you then save the script locally, you can use an option to prompt you for each update if you wish.
Here is a direct link to video:
This video will show you the process of setting up PowerShell on a new clean Windows 10 environment to support working with Microsoft 365. Basically, you grab my free set up script here –
and paste that into an elevated PowerShell window and run it. The required PowerShell cloud modules will then be installed into your environment, making it ready to connect to Microsoft 365, Azure, Intune, etc.
Here is a direct link to the video:
There are current concerns around:
Microsoft MSHTML Remote Code Execution Vulnerability
which is yet to have a patch made available.
I found this excellent article:
CLICK ME IF YOU CAN, OFFICE SOCIAL ENGINEERING WITH EMBEDDED OBJECTS
which provide some PowerShell scripts to create Word documents that can be used to test for the vulnerability.
I have run these scripts to create the actual Word documents and uploaded them for you here:
Office365/example at master · directorcia/Office365 (github.com)
In both cases, when you open these documents, you should NOT be able to get CALC.EXE to execute on your system unlike what you see above and below.
I have also added these tests to my security testing script which you can download from my GitHub repo here:
Office365/sec-test.ps1 at master · directorcia/Office365 (github.com)
When I opened these documents in my production environment, the vulnerability was largely blocked thanks to Windows ASR which I have detailed previously:
Attack surface reduction for Windows 10
You can use the follow KQL query as I did above to view the result of this blocking if you are using something like Azure Sentinel like I am:
Another great security add on for Microsoft 365
| where ActionType startswith ‘Asr’
CVE-2021-36934/CVE-2021-36934.ps1 at main · JoranSlingerland/CVE-2021-36934 (github.com)
I have update my security testing script here:
To now also test for this and report back as shown above. If you want to actually run the recommended fixes then run Joran’s script, my security script only tests for the issue.
I have made some updates to my free security test script:
The main improvement is the inclusion of a menu that allows you to select which test you want to run.
You can use the CTRL and SHIFT key to make multiple selections here.
The video also shows the results when the test script is run on a Windows 10 environment with Trend Micro and a Chrome browser.
Don’t forget to keep checking back for further script updates and improvements.