Why does command and control tunnelled through a trusted SaaS app clear EDR, proxy and identity checks alike?

## The technique, stated plainly An adversary carries tasking and results inside a legitimate software-as-a-service application's own API — messages, threads or file uploads in a collaboration workspace. ATT&CK groups this as web-service command and control (`T1102`, with bidirectional variants). Nothing exotic happens on the wire: it is HTTPS to a well-known vendor domain, often from the vendor's own genuine, signed client or via a valid API token. ## What each control class actually decides on **The endpoint product** decides over host telemetry: process creation with command line and parent image, module loads, file and registry writes, connection metadata. Here the process is the vendor's real client or a legitimate scripting host with a valid token; nothing unsigned is dropped, no injection is needed, the parent-child chain is ordinary. No rule matches, and the verdict is `clean`. That verdict is true within its surface. **The web proxy or secure web gateway** decides on the destination and the policy attached to it. The domain is categorised as business collaboration and permitted, because the organisation genuinely uses it. Where TLS is not intercepted for that category — common, both for performance and because vendors pin or the platform's client refuses interception — a passive observer sees the TLS server name, the certificate subject, timestamps and byte counts, and **no payload whatsoever**. The verdict `allowed` is not even an opinion about maliciousness; it is a policy decision about a category. Even where interception is in place, the traffic is well-formed API calls to that vendor's real endpoints, indistinguishable in shape from the same client doing work. **The identity provider's protection** decides about the authentication: is this sign-in consistent with what it knows about the principal. If the adversary is using a valid session or a token they already hold, there may be no new sign-in to judge. If the workspace being used for tasking lives in the adversary's *own* tenant rather than yours, your identity provider never sees the account involved at all. It can only score events it is party to. ## The real answer: correlated blindness Three products, three decision inputs, one shared assumption — *traffic from a signed client, to a trusted business domain, under a valid session, is work*. The technique is built precisely on that assumption, so it defeats all three at once. This is the difference between **overlap** and **depth**: - **Overlap** is two controls that would both catch the same technique. It buys resilience against one product being down, misconfigured or bypassed, and it costs licence, integration, an extra queue and reconciliation time when the two disagree. - **Depth** is controls whose *blind spots differ*, so a technique that clears one still runs into another. Three consoles that share a blind spot are not defence in depth; they are one control with three invoices. Agreement between controls therefore carries far less information than analysts assume. Two `benign` verdicts from products that never observed the behaviour in question are **silence, not corroboration**, and silence should not outvote a single control that did observe the relevant surface. ## What would actually have a chance here Ask which surface the behaviour has to touch, then find a control that watches that surface: | What the technique must do | Surface that records it | | --- | --- | | Authenticate to a workspace or tenant | The SaaS platform's own audit trail: account, app, OAuth grant, source address | | Get an application authorised in your tenant | Consent and app-grant records in the identity platform | | Reach the platform from a host | Asset context — which host classes have any business talking to it | | Move data through the platform | The platform's own file and export records, and egress volume from that host class | The most useful of these is the platform's own audit trail, because it is the one observer that sits *inside* the trusted channel: it is not defeated by the traffic being encrypted, to a trusted domain, from a signed client. The second most useful is asset context. A finance laptop talking to a collaboration workspace is unremarkable; a build agent or a domain controller doing it is a claim worth testing regardless of what any of the three consoles concluded. ## The trap to avoid in the answer Do not answer "the products are bad, buy a better one". Each control returned a correct verdict about the thing it observes. The gap is not accuracy; it is **independence**. When you next evaluate a control, the question is not "does it detect malicious traffic" but "which surface does it observe that my existing controls cannot, and which technique would it therefore decide correctly when the others are blind".