Your EDR vendor flags unfamiliar console API use; how do you separate your SOC's commands from an intruder's?

## The situation The discovery route here is worth naming, because it is common and it changes your starting position: the platform vendor's own abuse team noticed anomalous console API use and told you. Nothing fired internally, so you begin with no case, no alert, and a period of unknown length in which someone with response privilege may have been acting on your estate — using the same verbs your analysts use, producing the same host-side artefacts. Your job as the examiner is to produce a defensible split of console activity into *ours* and *not ours*, and to be honest about the part that cannot be split. ## Preserve before you analyse In a fully vendor-hosted console the administrative audit trail has no copy inside your estate, its retention window is set by the vendor, and console administrator rights can create and delete objects within the platform. So the first action is an export of the full window — operator authentications, role and permission grants, API-client lifecycle events, and per-command response history — into storage you control, along with a note of who exported it, when, and by what method. That note is what lets the reconstruction be defended later; without it your evidence is a spreadsheet of uncertain provenance. ## Build the principal timeline Sort every entry by the principal that submitted it, then within a principal by session. You are looking at four object types: - **Authentications** — which operators logged in, from what addresses, with what authentication method, and whether any session outlived its usual pattern. - **Grants** — role changes, especially any principal that gained an execute-everywhere role during the window. - **API clients** — creation, the role attached, and which principal created them. This is the persistence to look for: a new client with the same execute role survives a password reset and is easy to overlook because it looks like an integration. - **Commands** — the per-command history: verb, arguments, target, outcome. ## Reconcile against your own records This is the step that does the actual separating, and it only works if you set it up beforehand. For each command ask three things: **is there a case it belongs to**, **was the named operator on shift and would they have been working that case**, and **is the source address consistent with how that operator connects**. Legitimate response work usually reconciles on all three, and the SOC's own case notes should mention the collection or containment at roughly the right time. What fails to reconcile is your candidate set. Typical shapes: - Commands submitted by an API client that no integration owner claims. - A named operator's session from an address they have never used, at an hour they were not rostered. - Verbs your team does not use — mass collection across hundreds of hosts, exclusion changes, sensor removal. - Commands with no case and no note. Call these hypotheses. A rostered analyst working an urgent case from a hotel network fails two of the three tests and is entirely innocent; the reconciliation narrows the field, it does not decide. ## Corroborate on the host Console history records what was **submitted by an authenticated principal**. It does not prove the command ran, that it ran to completion, or what it produced. So pair each candidate command with the endpoint's own process telemetry for that host and time: the effects appear as children of the agent process, and there you can see the actual command line, exit behaviour, and any files written or connections made. Two useful outcomes come out of this pairing — you learn what the intruder achieved rather than what they tried, and you sometimes find agent-child activity with **no** matching console entry, which points at a different execution path and changes the scope of the investigation. ## Eviction is a separate list Separating past activity is not removing present access, and the two get conflated under pressure. Removing an operator's password does not revoke an active console session, an issued bearer token, or an API client created during the window. Eviction here means enumerating and revoking the platform's own objects — sessions, tokens, API clients, role grants made in the window — and checking the identity provider for scopes granted to the platform's service principal, because an integration authorised to read mail or directory data is access that outlives the console credential entirely. ## What you say about the ambiguous middle Some commands will reconcile weakly: the right operator, the right period, no case reference because the team does not use one consistently. Say so, plainly, and say what would have resolved it — a case identifier on every command, individual federated operator identities, an exported trail. An examiner who presents a clean binary split they cannot support is far weaker than one who states the confident set, the ambiguous set, and the specific evidence that would move entries between them.