What evidence may show abuse of a trusted service?¶

Abuse of a trusted service is best shown by linking the service-side instruction to its delivery and the resulting activity on a target. Neither a trusted agent, signed binary nor familiar cloud address proves that the action was authorised.

The strongest account usually combines control-plane records with evidence from the systems on which the instruction took effect.

Build the chain across both sides¶

Service records may show an operator login, API call, uploaded object, workflow, deployment or target list. Endpoint and network records may then show the corresponding process, file, connection or configuration change.

Preserve native identifiers that connect these layers, including:

• tenant, account, session and token identifiers;
• job, run, workflow, object or deployment identifiers;
• scripts, packages, parameters and target lists;
• creation, approval, queue and execution times; and
• per-target results and later endpoint effects.

Service-specific terms should be retained in the notes and explained in the report. Translating every action into a generic "command" too early can discard distinctions that matter to platform specialists or later verification.

Distinguish human decisions from automation¶

One configuration change may cause a service to perform hundreds of later actions. Separate the person or session that created the rule from service accounts that executed it and from each target result. Repeated endpoint events do not necessarily represent repeated human decisions.

Finally, assess who controlled the initiating account. Subscriber details and account names may identify a contractual user, another victim or a shared identity rather than the individual responsible for the action.

This evidence structure provides the basis for the careful reporting distinctions in the next card.