Email remains the most common way intruders first reach an organization, and collaboration platforms have become the place a compromise pays off. The two belong in one discussion because they are now one system: a mailbox, a file store, a chat service and an identity, sold together and compromised together.
This article covers what protects the channel, what limits the damage when the channel fails, and the platform settings that determine which of those two outcomes you get.
Business email compromise, and why it defeats content filtering
The most expensive email incidents involve no malware. An attacker obtains access to a legitimate mailbox and uses it: reading the finance conversation, learning the vocabulary, and inserting a request for a payment change at a plausible moment.
Content filtering cannot address this, because there is no malicious content. The message is a genuine message, from a genuine account, inside a genuine thread. Detection has to shift to the account instead: where it signed in from, what rules were created on the mailbox, whether messages are being auto forwarded, and whether the sign in pattern changed.
The forwarding rule is the classic indicator. An intruder creates a rule that moves replies containing certain keywords into an obscure folder, so that the legitimate owner does not see the conversation being conducted on their behalf. Alerting on mailbox rule creation is cheap, high signal and frequently not enabled.
The process control matters more than any of this. A payment instruction change verified through a channel other than the one it arrived on defeats the attack regardless of how convincing the message was, and is the single most effective countermeasure available.
Sender authentication
Three mechanisms let a receiving system judge whether mail claiming to be from your domain really is. They are widely deployed in weak configurations.
The first publishes which servers may send for your domain. The second attaches a signature that survives transit. The third states what receivers should do when the first two fail, and reports back on what is being attempted in your name.
The common failure is stopping at the permissive setting. A policy that asks receivers to take no action on failures protects nobody; it merely produces reports. Moving to an enforcing policy takes work, because it requires finding every legitimate sender including marketing platforms, ticketing systems and applications that send on your behalf, and that inventory is exactly why the work gets deferred. It is worth completing, because until it is, anyone can send mail as your organization.
These controls protect other people from mail impersonating you. They do nothing about mail arriving at your organization, which is a separate set of controls, and conflating the two is a common misreading.
Links, attachments and the limits of scanning
Inbound protection scans attachments and evaluates links. Both help and both have known limits.
Attachment scanning finds known malicious files and detonates unknown ones in a sandbox. Attackers respond with password protected archives, files that behave benignly under analysis, and formats that abuse legitimate features rather than carrying code.
Link protection rewrites URLs so they are evaluated at click time rather than at delivery, which addresses the common tactic of sending a benign link and weaponizing the destination afterwards. Its limit is that a credential harvesting page on a reputable hosting service, newly registered and not yet categorized, frequently passes.
This is why the layer that actually holds is authentication rather than filtering. If a harvested password is not sufficient to sign in, the phishing page has cost the attacker time and gained them little.
Multifactor authentication, and the exclusions that matter
Multifactor authentication on mail and collaboration access is the highest value control in this area. Its weakness in practice is coverage rather than concept, which is discussed in identity and access management.
Two exclusions are worth naming here because they are specific to this platform. Legacy authentication protocols, which cannot present a second factor and are frequently left enabled for an old client or a device, provide a path that bypasses the control entirely. And shared or departmental mailboxes accessed by several people often end up with a shared password outside the normal identity process.
Attackers know both. Disabling legacy protocols is usually the single highest value configuration change available on a modern mail platform, and it is deferred because somebody might still need them, which is a question that can be answered from sign in logs rather than assumed.
What happens after a mailbox is compromised
Assume the control fails, because eventually one will. What limits the damage is what the account can reach.
A compromised mailbox in a tightly configured environment yields that user's mail. The same compromise in a permissive one yields the mail, the shared drives that user could open, the chat history, any site they were granted access to years ago, and the ability to send internally with the trust an internal sender enjoys.
The settings that make the difference are sharing defaults, particularly whether links can be created that work for anyone who has them; guest access, and whether external participants persist after a project ends; and the accumulation of access to collaboration sites, which follows exactly the pattern described for permissions generally.
Data loss controls belong here too, applied to the paths by which information actually leaves: auto forwarding to external addresses, bulk downloads from file stores, and sharing links sent outside the organization.
Token theft, and why a second factor is not the end of the story
Multifactor authentication defeats a stolen password. It does not defeat a stolen session.
Once a user has authenticated, the platform issues a token that proves the session is already trusted. An attacker who obtains that token, through a proxy that sits between the user and the real sign in page, or through malware on the device, can use the session without ever presenting a factor. From the platform's perspective the request arrives already authenticated.
Three things reduce the exposure. Phishing resistant authentication methods, which bind the credential to the legitimate site and fail on a proxy. Conditional access requiring a managed, compliant device, so that a token replayed from elsewhere does not satisfy the policy. And shorter session lifetimes for high privilege accounts, accepting the friction in exchange for a smaller window.
This is worth stating plainly because organizations that have deployed multifactor sometimes treat account compromise as solved. It is substantially reduced and not eliminated, and the detections described below are what catch the remainder.
Shared mailboxes, aliases and departed staff
Mail systems accumulate objects that outlive the people who created them. A shared mailbox for a project that ended. An alias pointing at a former employee. A distribution list that still delivers externally. A mailbox kept active after a departure because a manager wanted access to the history.
Each is a small exposure and together they form a category nobody owns. A departed employee's mailbox left enabled is a credential that can still be attacked with nobody watching for misuse of it. A distribution list that accepts external mail and delivers internally is a path around sender checks.
The remedy is periodic review of mail objects as objects, not only of user accounts: what exists, who owns it, whether it still has a purpose, and whether it should accept mail from outside.
Awareness, honestly framed
User awareness training is worth doing and is routinely oversold. People can be taught to recognize obvious phishing, and a well constructed message targeting a specific person in a specific role will still succeed some of the time. A program whose security model depends on nobody ever clicking is not a security model.
What training reliably improves is reporting. A workforce that reports suspicious messages promptly, and is thanked rather than blamed for doing so, gives the response function early warning that no filter provides. Measuring reporting rate is more useful than measuring click rate, because the first is an outcome you want and the second is a number that can be improved by making tests easier.
Logging and detection specific to this surface
The signals worth collecting are sign in events with location and device, mailbox rule creation and modification, mass download or deletion, permission changes on collaboration sites, and the creation of external sharing links. Most are available and not all are enabled by default.
The detection that pays for itself is the impossible travel and unusual location sign in, because it catches the compromise before the fraud, which is the only point at which it is cheap. Collection practice is covered in security monitoring and incident detection.
Running it as a service
Collaboration platforms change frequently, and the vendor's defaults move with them. A setting reviewed at deployment is not the setting in force two years later, which is the drift argument made throughout the managed cybersecurity lifecycle.
LABUSA operates mail and collaboration platform configuration, authentication policy, sender authentication and the associated monitoring within managed cybersecurity and collaboration platform operations, alongside the cloud configuration work described in cloud security.
Sources
- NIST, Digital Identity Guidelines: Authentication and Lifecycle Management, SP 800-63B.
- NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29, February 2024.
- Center for Internet Security, The 18 CIS Critical Security Controls.