When implementing Attack Surface reduction policies. The following configurations should be set in audit mode to allow you to compile an inventory of Microsoft Word, Excel , Outlook etc, add – in child processes.
If you simply block all the of the options illustrated below, then can possibly block Microsoft Office add-ins.
A good way to analyse Microsoft Office add-ins, is to review endpoint analytics in the Microsoft Intune portal.
Start with audit mode, compile an inventory of what Microsoft add – ins, create child processes, analyse the audit mode for the three controls illustrated below via KQL queries and finally a risk assessment on all Microsoft Office add-ins, only then can you whitelist line of business Microsoft add-ins that have passed a risk assessment.
Microsoft Defender for Endpoint is a next generation XDR solution
Some of the items that really What sets Microsoft’s next generation XDR solution for endpoints ahead of alternative vendor XDR solutions are listed below.
5 device licenses per user , Windows, Android, iOS, Linux, macOS
Defender to Endpoint integration with Defender for 365
Defender for Endpoint integration with Defender for Cloud Apps
Defender for Endpoint Web Filtering
Defender for Endpoint Vulnerability – Inventories , Recommendations, Weakness Reports, Event Time Lines
Advanced Hunting
Custom Detection Rules
Azure Sentinel integration
Protect internet facing devices
Intune integration
Automated investigation and remediation
Auto Isolation of devices that are classified as a high severity risk via Power Automate or Logic Apps
Power Automate approval workflow for isolation of medium severity risk devices
Cloud Security Analytics
Consult Threat experts
Initiate Live Response Session
Collect investigation package
Run antivirus scan
Restrict app execution
Isolate device
Contain device
The Microsoft Security portal can provide advanced hunting KQL queries to assess the impact on an organisation’s newly configured security policies, prior to implementation.
An organisation should always improve the Microsoft Defender Vulnerability Management dashboard : exposure score, before choosing the auto remediation policy methods.
If there is an existing endpoint detection response solution, configure Microsoft Defender for Endpoint in EDR mode, to demonstrate all the vulnerabilities that the primary endpoint detection response solution does not report or remediate.
The next step will be to configure the automation remediation level to ‘Semi – require approval for core folders’, until Microsoft Defender for Endpoint, machine learning and cloud intelligence has, provided an organisation will all security and remediation metrics. Then ‘Full – remediate threats automatically’ can be enabled, and integrated with Microsoft Sentinel. SIEM without SOAR is useless.
Simply enabling ‘Full – remediate threats automatically’, may cause problems with certain applications. Every organisation is different and has different line of business applications.
In previous times, email, black and white lists were always implemented, the same way end point detection and response solutions, processes or folders were excluded from protection.
It is now recommended to configure as few exclusions as possible, with the advances in technologies like machine learning and AI. Machine learning and AI, can identify vulnerabilities that are unique to an organisation. The Microsoft Security Center processes more IT transactions daily and globally than any other security vendor in the world, and will most likely provide protection against zero day vulnerabilities than any other global security vendor.
No security vendor can claim to provide protection against a zero day vulnerability, however Microsoft Defender for Endpoint can dynamically provide protection, when analysing malicious behaviour via multiple methods like heuristic behaviour and are not dependent on security vulnerability signatures that have already been defined.
At the time of writing this blog, Microsoft Intune can provide the following amount of Microsoft Edge and Google Chrome configuration and control options.
When attempting to federate a domain hosted in Exchange on premises with Exchange Online. The error message displayed below appears.
To resolve this issue TLS 1.2 needs to be enabled on the Exchange Hybrid servers.
ALI TAJRAN has a excellent ARTICLE and script to enable TLS 1.2 on Exchange servers. Once this script has run on the Exchange Hybrid servers, the wizard to add a federated domain will complete successfully.
Note: TLS 1.3 is not supported on Exchange on premises yet.
When the Azure Active Directory Premium password protection service was first released, it was well received.
There a few issues with the Azure AD Premium ‘Password Protection’ service.
1: An enterprise customer will block internet access on all domain controllers 2: If using the Azure AD Premium ‘Password Protection’ service, it requires an agent installed on all domain controllers, this agent will then, communicate with a proxy agent to establish access to Azure AD. For example , ‘agent on dc’s’ communicates to agent on ‘AD Connect server’ 3: Microsoft Defender for Identity domain controller agent, cannot co-exist with the Azure AD Premium ‘Password Protection’ service agent, on the same domain controller 4: Microsoft Defender for Identity service will significantly improve an organisation’s security posture in comparison to the Azure AD Premium ‘Password Protection’ service 5: A much easier and secure method of Identity Management, is to enable the Microsoft Active Directory Premium and Microsoft Authenticator services to use: Passwordless authentication.
Passwordless can protect against
BruteForce Attacks Password Spray Attacks.
Enabling passwordless , can also help organisations, to get one step further in their Zero Trust journey
When an organisation has completely transitioned and migrated to Exchange Online and directed their MX record to contoso-com.mail.protection.outlook.com. The organisation should in line with best practices, have Microsoft Defender for Office365 Plan 2 securely configured.
Scenario 3, this my proffered choice. All Contoso *.onmicrosoft.com aliases can be blocked as they are no longer required. When Contoso’s mx record has been directed at Exchange Online protection. Exchange Online Protection & Microsoft Defender for 365 will protect all aliases. It may not even be necessary to block all Contoso *.onmicrosoft.com aliases.
It is possible to create an email address policy for Office365 groups that only use’s @contoso.com primary email addresses, which can still allow mail flow to Team’s channels. Then the usual protection of contoso.com comes into play, SPF, DKIM and finally DMARC.
Some organisations do not use Exchange Online Protection and Microsoft Defender for 365 to protect their Exchange Online tenant and use 3rd party message hygiene services like Mimecast and Proof Point. This blog will demonstrate a a scenario where securing Exchange Online message routing is configured incorrectly and could be classified a vulnerability,
SCENARIO 2
1. Contoso.com MX record is pointed at Mimecast; Mimecast provides spam protection 2. Mimecast then passes the messages to Exchange Online 3. If there are any remaining Exchange on-premise recipients, Exchange online will route the messages to the Exchange Hybrid servers via the secure Exchange Hybrid connectors 3. The Exchange Online inbound connector that accepts traffic from the Mimecast service is secured via TLS
VULNERABILITY Anyone in the world can send an email to to an Exchange Online recipient with a *.mail.onmicrosoft.com or *.onmicrosoft.com alias, when sending to these domains. The messages completely bypasses , the organisation’s Mimecast’s message hygiene services and can route messages to Exchange Online recipients and Exchange on-premise recipients. If the organisation has not configured Exchange Online protection and Microsoft Defender for 365, then the organisation is vulnerable to malware and phishing emails.
Another problem: Office365 groups, When a Teams Channel is created, it creates an Office365 group that will have a *.onmicrosoft.com alias. Bad actors sending emails to these aliases can once again completely bypass the organisation’s message hygiene services.
SOLUTION The Hybrid configuration wizard creates an Exchange Online inbound connector that is locked down with TLS via a public trusted certificate on the Exchange Hybrid servers.
The default inbound Exchange Online connector that was created by the Exchange Hybrid wizard, can be modified to only accept inbound messages from the IP ranges of the Mimecast service and TLS.
This script queries the existing inbound connector and creates an inbound connector that blocks messages recipients using the *.mail.onmicrosoft.com to only accept traffic from a service using the TLS certificate and connector that has been modified or it can query a new inbound connector
In this scenario , when a message is sent to an Exchange online recipient , the message flows as follows. 1. MX contoso.com 2. Mimecast 3. Contoso.com aliases & all consto.com *.onmicrosoft.com will only accept messages from Mimecast
Note: run this script using the latest Exchange Online PowerShell module
New-InboundConnector -Name ‘Restrict inbound mail flow to hybrid domains’ -ConnectorType Partner -SenderDomains * -TlsSenderCertificateName (Get-InboundConnector $InboundConnectorName).TlsSenderCertificateName -RestrictDomainsToCertificate $true -RequireTls $true
Some organisations do not use Exchange Online Protection and Microsoft Defender for 365 to protect their Exchange Online tenant and use 3rd party message hygiene services like Mimecast and Proof Point. This blog will demonstrate a scenario where securing Exchange Online message routing is configured incorrectly and could be classified as a vulnerability,
SCENARIO 1
In the scenario above , this could be one of the most typical Exchange Online topologies. 1. Contoso.com MX record is pointed at Mimecast, Mimecast provides spam protection 2. Mimecast then passes the messages to Proof Point, and Proof Point, performs malware inspection on the messages. 3. Proofpoint then routes the messages to the on-premises Exchange Hybrid platform. 4. Exchange Hybrid forwards messages to Exchange Online recipients via the Exchange Hybrid connector and the mail flow source Exchange Hybrid server communicates directly with Exchange Online and does not route via Mimecast or Proof Point. 5. The Exchange Online inbound connector that accepts traffic from the Exchange Hybrid servers is secured via TLS.
VULNERABILITY Anyone in the world can send an email to an Exchange Online recipient with a *.mail.onmicrosoft.com or *.onmicrosoft.com alias, when sending to these domains. The messages completely bypasses , the organisation’s Mimecast and Proofpoint message hygiene services. If the organisation has not configured Exchange Online protection and Microsoft Defender for 365, then the organisation is vulnerable to malware and phishing emails.
Another problem: Office365 groups, When a Teams Channel is created, it creates an Office365 group that will have a *.onmicrosoft.com alias. Bad actors sending emails to these aliases can once again completely bypass the organisation’s message hygiene services.
SOLUTION The Hybrid configuration wizard creates an Exchange Online inbound connector that is locked down with TLS via a public trusted certificate on the Exchange Hybrid servers.
This script queries the existing inbound connector and creates an inbound connector that blocks messages routed to *.onmicrosoft.com recipients, to only accept traffic from the Hybrid servers that are using the matching TLS certifictate.
In this scenario , when a message is sent to an Exchange online recipient , the message flows as follows. 1. MX contoso.com 2. Mimecast 3. Proof Point 4. Exchange on-premises 5. Exchange on-premise forwards the message to the Exchange Online recipient’s *.mail.onmicrosoft.com alias.
Note: run this script using the latest Exchange Online PowerShell module
New-InboundConnector -Name ‘Restrict inbound mail flow to hybrid domains’ -ConnectorType Partner -SenderDomains * -TlsSenderCertificateName (Get-InboundConnector $InboundConnectorName).TlsSenderCertificateName -RestrictDomainsToCertificate $true -RequireTls $true
The image above is a high level overview of all identity protection methods regardless of vendor and especially when it comes to implementing Zero Trust. A lot of organisations do not really know what Zero Trust is, or how to begin their Zero Trust journey.
Zero Trust is a bit like Data Classification, it becomes an operational task that will never end. It is not implemented as a project but more as an operational procedure, that constantly evolves as threats and data protection requirements evolve. I have not yet seen a Zero Trust request from an organisation yet that are exactly the same. Zero Trust strategies can often be similar per industry like , legal, pharma, manufacturing and food industry etc..
The purpose of this blog post is to show how Azure Identity Protection and Microsoft Defender for Identity protection work together and can improve any organisation’s security posture as Identity is the new security plane and the days of protecting identity behind edge perimeter firewalls are no longer relevant.
Not all organisations’ (like SMB) can afford Microsoft Azure Identity Protection. I normally advise SMB organisations to procure Azure AD Premium plan 2 licenses to protect any privileged accounts.
For enterprise organisations that are licensed for Azure Identity protection, my preference for implementing the Azure Identity Protection controls, is via Conditional Access. This provides additional insights when placing the policies in report mode only and then reviewing the reports in Conditional Access – Insights and Reporting.
Azure Active Directory Topology
The image above illustrates Azure ADDS (Active Directory Domain Services) and Azure AD. So, think of Azure Identity Protection, as a service protecting identity at the cloud level or like the traditional perimeter edge firewall for ADDS. Microsoft Defender for Identity, protects on-premise identities.
Microsoft Azure Identity Protection
Identity Protection is a tool that allows organizations to accomplish three key tasks:
Identity Protection uses the learnings Microsoft has acquired from their position in organizations with Azure AD, the consumer space with Microsoft Accounts, and in gaming with Xbox to protect your users. Microsoft analyses 6.5 trillion signals per day to identify and protect customers from threats
Microsoft Defender for Identity
Microsoft Defender for Identity monitors domain controllers by capturing and parsing network traffic and leveraging Windows events directly from domain controllers, then analyses the data for attacks and threats. Utilizing profiling, deterministic detection, machine learning, and behavioural algorithms Defender for Identity learns about your network, enables detection of anomalies, and warns you of suspicious activities.
Microsoft Defender for Identity provides alerts to suspicious lateral movements in an on-premise network with ADDS identities. The alerts are great but can only be actioned as soon as a Security staff member can respond to the alerts.
The two automated responses that Microsoft for Identity can perform are:
Disable user – this will temporarily prevent a user from logging in to the network. This can help prevent compromised users from moving laterally and attempting to exfiltrate data or further compromise the network.
Reset user password – this will prompt the user to change their password on the next logon, ensuring that this account cannot be used for further impersonation attempts.
Typically, all enterprise organisation’s do not permit internet access on their domain controllers, except for port 53 (DNS) or port 123 (Network Time Protocol), but most normally domain controllers internet connectivity is controlled by proxies
The Azure AD Premium P1 and P2 password protection service, provides an excellent topology. An agent is installed on domain controllers that then communicates with a proxy agent installed on a server, that has internet access, like an AD connect server.
Microsoft Defender for Identity standalone sensor
The standalone sensor requires two network adapters. 1: Management Adapter: used for communications on your corporate network 2: Capture adapter: used to capture traffic to and from the domain controllers
The below ports are required to be configured for standalone sensor
Azure Sentinel
Playbooks may be available in the future that can perform more automated remediation tasks with Microsoft Defender for Identity.
Microsoft have provided an online demonstration on how to compromise an identity and take control of a domain, which I find hard to believe, however, it is a bit like ethical hacking. Security professionals must know the lateral movements of a bad actor when attempting to compromise an identity and an on-premise Active Directory domain.
Microsoft Defender for Identity also provides some recommendations, when the Microsoft for Defender Identity sensors (agents) have gathered telemetry information on an on-premise Active Directory instance. An example would be ‘implement secure LDAP’, when an organisation reviews the recommendations provided by Microsoft Defender for Identity, some careful planning is required to assess the impact of implementing the recommendations that Microsoft Defender for Identity has provided.
When Azure Identity Protection and Microsoft Defender for Identity, has been fully implemented in an organisation, it will really improve the organisation’s security posture and Microsoft will continually develop these services to protect against existing and future vulnerabilities.
One of my colleagues Mark Doyle highlighted an issue with QMMA for Windows Server 2019 and 2022 domain controllers. Without these commands run on the 2019 and 2022 domain controllers the DSA agent server could not successfully migrate user accounts and SID history.
So my colleague Mark Doyle stuck at it , and even the Windows Server 2019 or 2022 firewall may state that it is off, it kind of isn’t.
So to resolve this issue we had run a couple of commands on the new 2919\2022 domain controllers and the problem was solved , so here are the commands.
Microsoft have released a new feature in Conditional Access where named locations can be defined by country GPS coordinates. The Microsoft Article can be referenced HERE
This is a great improvement in protecting against bad actors. A lot of my customers’ often ask me to create a conditional access policy to block access for all countries except Europe, Ireland and the UK. Bad actors could simply use a vpn and then specify what country they are connecting from which can then by-pass the conditional access blocking bad actors based on country IP, where they cannot by pass GPS coordinates
Cloud-Secure.ai 