Monitoring the Microsoft 365 ecosystem is doable. However, 10 years after its beta release, M365 is still under evolution and changes to core functions still happen. Its default logging options are not always what most users need, but they can be adjusted
to suit almost any organization. This piece outlines some key logging rules and detection logic that can help uncover common risks within M365 environments.
Challenges Monitoring M365
Across all market verticals, M365 customers struggle to monitor their environments effectively. Microsoft provides ample logging options, but due to an ongoing stream of new feature enhancements and introductions of entirely new tools, adequate logging
is a continually moving target. This means standards from groups like the Center for Internet Security (CIS) and NIST are lagging. Fortunately, Microsoft is leading the charge to fill in this gap by providing reasonable logging suggestions as new
features roll out.
A quick check of recent breach announcements shows many organizations struggle to maintain minimum standards of due care. In M365’s case, changes to the cloud offering are now outpacing what most organizations can tolerate. In response, many are
either doubling down on their efforts or looking to external providers to manage these changes. Regardless of the course taken, organizations must take active steps to ensure they are keeping up.
Threat of Business Email Compromise
Cloud office ecosystems have many risks, and perhaps the largest is the threat of business email compromise (BEC). This problem affects all cloud providers. Oddly enough, attackers are “forced” toward BEC attacks due to increased security
provided by the cloud providers. BEC is a type of hijack attack that has been on the rise for two main reasons:
- Bigger payoffs: In cloud ecosystems, stealing a user’s credentials gives attackers full access to all the data and systems the user has rights to. User hijacks have never had such a great payoff.
- Tighter system security: The second driver is the native security of cloud solutions. Because attackers cannot typically gain access to cloud infrastructure, they refocus efforts that would be spent attacking systems and go after users instead.
M365 Detection Rules
To counter BEC attacks, many organizations find it helpful to create detections based on the earliest indicators of the attack. In the security administration center of M365, the following default rules can be helpful:
- Creation of forwarding/redirect rule: This rule creates an alert whenever users set up a forwarding or redirect rule in their mailbox. This rule is listed as low severity, but I believe it should be much higher. This rule is especially effective in
BEC scenarios because attackers will create mailbox folders, and auto-forwarding and redirect rules to hide traffic. This prevents messages from appearing in the sent folder, as well as hides any replies or bounce-back messages. While this rule
does create a few false positive alerts, its usefulness usually outweighs any issues.
- Suspicious email forward patterns detected: Although it is set to a default of medium severity, this is one of the most used alerts to find accounts that have been hijacked. All too often, defenders worry about inbound issues, without considering
outbound mail analysis, which can be a strong detection.
M365 Detection Triggers
Although not enabled by default, multiple other detection triggers should be explored. Two useful detection triggers based on observed attacker behavior are:
- User agents: M365 allows administrators to adjust the enforcement of security rules based on user agent strings. Because user agent strings are identifiers of the client software, they are an easy way to provide exceptions to rules for scripts or
other administrative tools. There are two trigger condition potentials here: “added exempt user agents” and “changed exempt user agents.” These rules should almost never fire unless they are part of an expected configuration
change. They most often indicate an attacker has created an exception list and is in the process of configuring a way to bypass detection.
- Unexpected device: Users tend to log in to systems using the same devices over and over. This quirk allows for crisp detection logics. When a new device is used to access your M365 instance, send an alert. Organizations who enable this alert will
periodically get false positives when users swap out devices. If specific users do this frequently, this alert can be suppressed by placing frequent swappers in an exception group.
M365 Log Collection and Retention
The SolarWinds breach shifted attention to supply chain attacks. As a result, many organizations are revisiting their log collection and retention strategies. The SolarWinds attack leveraged techniques difficult to detect for most organizations, enabling it
to remain undetected for over nine months.
To combat these types of attacks, focus on attackers’ post-access activities. Early indicators of advanced adversaries potentially gaining access to your environment can include, but are not necessarily limited to:
- Unauthorized changes to configurations
- Unexpected interactions
- Atypical data access volumes
- Consider leveraging the statistical functions in a SIEM or use Power BI/flow to facilitate this deeper analysis.
READ: How to Detect and Remediate M365 & SSO Impacts of SolarWinds
M365 Logging and Monitoring Tips
Logging within M365 can be difficult because the product continues to evolve, with new features and tools added constantly. Consider the following tips help ensure you continue to log and detect what’s important in M365:
- Take a use case-based approach and ensure you have logging in place to cover each one.
- Review Microsoft’s logging recommendations on a regular basis. They will be the most current for the foreseeable future.
- Beware older information. Rapid evolution of features means information over three months old is likely dated.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.