Detecting Malicious Activity in Microsoft 365

Microsoft 365 has a particular problem that endpoint security never had: the attacker and the legitimate user look almost identical. A threat actor who lands inside a mailbox is not dropping a payload or spawning a suspicious process. They are reading mail, creating a forwarding rule, sharing a SharePoint file, logging in. The infrastructure they need is already there, provisioned and trusted, and they use it the way an employee would. That is the tension running underneath this session between Matt Bromiley of LimaCharlie and Paul Ihme, co-founder of the Charleston security firm Soteria. The two are nominally there to announce a managed set of Microsoft 365 detection rules Soteria has built for the platform. The more durable point is what those rules reveal about how you detect an adversary who never has to bring their own tools.

Behavior is the only thing that holds up in a cloud tenant

Soteria built its MDR practice on LimaCharlie starting around 2018, the same period the platform went from open source project to company, and its first detection work was endpoint focused. Ihme describes the philosophy that carried over: aim at the top of the Pyramid of Pain, behaviors and attack techniques, and stay away from indicators like IP addresses and file hashes that age out fast. In Microsoft 365 that discipline stops being a preference and becomes the only thing that works. As Ihme puts it, rules that watch for a known-bad IP hitting your tenant are "so fragile" they are barely worth writing. What survives is the behavior. The set spans the whole suite rather than just email: Entra ID and identity, Exchange mailboxes, SharePoint, OneDrive, Teams.

The identity surface is where the most interesting tradecraft shows up, because the attacks exploit how the platform is designed rather than any flaw in it. Ihme points to Federated domain creation, a move seen in both Microsoft and Okta environments, where instead of creating a new admin account that someone might notice, an attacker stands up a whole federated domain and then adds and removes users "pretty much invisibly." The rules also watch for legacy and basic authentication, and Bromiley extends the thought with a field story that makes the stakes concrete. Investigating intrusions, he kept seeing adversaries apparently running macOS 10.9, until he realized the mail client on that version defaulted to IMAP, a single-factor protocol, which let attackers sidestep MFA entirely. Microsoft has long said it would disable basic auth across all tenants. In Soteria's experience, Ihme notes dryly, that has not happened.

The detections that pay for themselves

Ihme is candid that ransomware gets the headlines while business email compromise "happens in the background and nobody hears about it," even though it is a billion-dollar industry with a far higher volume of incidents. That framing explains where the roughly 70 live detectors concentrate. The set catches inbox manipulation, the forwarding and tenant-wide transport rules attackers use to route or delete the messages they do not want a victim to see, along with security setting tampering, anonymous SharePoint sharing used to push malware, and side-loaded Teams apps. Bromiley singles out one detection, a new inbox rule created in Microsoft 365, and calls it "a billion-dollar rule" for its ability to interrupt money heading out the door.

What keeps that from becoming noise is restraint, and this is the part operators should pay attention to. An inbox rule is not malicious; it just happens to be malicious most of the time it matters. Soteria does not fire on every one. It filters the benign cases and concentrates on the tells: a rule forwarding to an external address, or messages routed into the folders attackers favor for hiding traffic, RSS feeds and conversation history among them. The set also escalates Microsoft's own high-fidelity alerts, anything arriving as an "alert generated" event such as impossible travel, treating the platform's native logic as table stakes and layering Soteria's detection logic on top. Each rule carries MITRE ATT&CK tags, which inside LimaCharlie become attributes an analyst can pivot and query against rather than static documentation.

Why this fits a provider running many tenants

The mechanics are deliberately thin. Microsoft 365 is a first-class cloud source in LimaCharlie, brought in through a cloud-to-cloud connector or, for teams that want a system in the middle such as a jump box, a self-managed forwarder. The connection is unidirectional, which does not stop detection or response against the telemetry as it streams. What arrives is not a search index but a timeline of streamable events where every field is observable and can be detected against in stream, so there is no separate step of writing queries against stored logs before a detection can fire. The operator workflow is short: subscribe to the Soteria rules, subscribe the tenant to the Tor lookup, configure the sensor. Both men agree the longest step is on Microsoft's side, turning on the audit logs.

For an MSSP or MDR, the appeal is consistent coverage across many tenants without standing up a detection engineering program per client, against a target that changes constantly. Soteria maintains the set aggressively, adding, editing, and retiring rules on a daily cadence, which matters because Microsoft renames and reshuffles this product faster than anyone can track. Ihme is firm that the set is a starting point, not a finish line. Providers should layer their own context on top, alerting on logins from outside a region where a client's team is known to work, and they should baseline each tenant before trusting the monitoring at all. As Ihme warns, MDR will not surface a compromise that predates it; you can deploy perfect monitoring and discover months later that the attacker was already inside. Soteria's open source 365 Inspect tool, and its SaaS version Soteria Spec, exist to check for the misconfigurations, federated domains, weak authentication, suspicious inbox rules, that should be fixed before an alert ever has to fire.

There is also a quieter benefit Bromiley raises that lands differently for a service provider. Depending on a customer's license tier, Microsoft retains audit logs for as little as 180 days. Pulled into LimaCharlie, those logs gain a full year of retention regardless. Licensing shapes what you can see as well: after the 2023 incident in which a nation-state actor reached Microsoft's backend, Microsoft committed to opening unified audit log access below the E5 tier, so E3 and above should generally carry the telemetry these rules need. Where the telemetry is not present, the detection simply does not fire. The honest version of cloud detection is that you are always working with what the vendor decides to log, on the schedule the vendor decides to log it, and the value of an outside platform is partly that it remembers longer and reasons over the stream the moment it arrives.