Your managed service provider says it was breached and its remote-support account in your estate may have been used — how do you scope it?

## Why this scoping runs backwards from a normal investigation A normal investigation starts from an alert and expands. Here you start from an *identity* that a third party says may have been abused, and you have no alert at all — because the account was doing exactly what it is authorised to do, from the places it is authorised to do it. Abuse of a trusted relationship is powerful precisely because it is indistinguishable, at the record level, from the service you pay for. So the scope is defined by reach first and by activity second. ## Step one: enumerate reach, on paper, before touching logs Write down everything the provider's access could touch if fully abused: - **Directory privilege.** Group memberships, nested groups, delegated rights on organisational units, and anything the account can reset or add itself to. A support account that can reset passwords can reach far past its own logon rights. - **Agent footprint.** The remote management and monitoring tooling the provider runs: which hosts have its agent, what it can execute, and whether it can push software fleet-wide. An agent that can run arbitrary commands everywhere is, functionally, domain-wide execution. - **Credentials it could read.** Vault entries, shared local administrator passwords, service account passwords in documentation, connection strings in scripts on the jump host. This is the part people forget, and it determines how far the blast radius outlives the account itself. - **Non-directory identities.** Cloud roles it can assume, SaaS admin roles, API keys, network device credentials, hypervisor and backup console access. Backup consoles are especially worth naming. - **Accounts it created or owns.** Service accounts and break-glass accounts stood up during onboarding are frequently forgotten and rarely rotated. This list is the scope. Anything on it is in the investigation whether or not you see the account touch it. ## Step two: reconstruct what the identity actually did, from records you hold You hold more than you think, and you should search it independently of anything the provider says: - **Remote-access session records** — VPN or zero-trust gateway logs give session start and end, source address and duration for every connection into your estate. - **Windows Security logons for that account across the fleet.** 4624 is a successful logon; logon type 10 is RemoteInteractive, which is what an RDP desktop session looks like, and type 3 is a network logon, which is what file-share and remote-administration access looks like. 4625 shows failures, which matter when someone is probing where the account can reach. 4634 and 4647 bound the sessions. A 1102 — the Security log was cleared — on any host the account touched is a finding by itself. - **Jump-host telemetry.** Endpoint process records, shell history and command lines from the bastion the provider works through; this is usually the highest-value single source in the whole scope. - **Cloud and SaaS control-plane audit trails** filtered to that principal: role assumptions, key creation, policy changes, tenant configuration. - **Linux estate.** Auth records and audit-daemon syscall records for the account's sessions, with `execve` records showing what was actually run where audit rules were configured to collect them. ## Step three: separate misuse from the day job The account logs on dozens of times a day legitimately, so volume tells you nothing. The discriminators are: - **Ticket correlation.** Authorised work has a change or incident ticket behind it. Sessions with no corresponding ticket are the shortlist. - **Scope deviation.** Hosts, subnets or tenants outside what the provider is contracted to manage — a support account touching the finance file server or a backup console is a different event from it touching a monitored web tier. - **Time-of-day and geography.** Off-hours sessions, or connections from source addresses outside the provider's usual egress, deserve individual explanation. - **Action shape.** Credential access, group membership changes, new persistent accounts, backup deletion, and log clearing are what an intruder does with borrowed support access; patching and health checks are not. Be honest about what a matching session record proves. A successful logon event proves a credential was accepted, not that the provider's engineer was present — and in this scenario that is precisely the point at issue. ## Step four: ask the provider for the narrow thing They hold what you do not: their remote management tool's own session records for your tenant, the identity of the affected credentials, and their determination of the window. Ask for those specifically rather than for 'your logs'. A provider that will not release its internal incident report will often confirm session metadata about connections into your estate. ## Step five: act on the access, not on the verdict Whichever way the evidence lands, the access itself is now untrusted: disable or re-issue the account, rotate every credential it could read, review anything it created, and reduce standing access to just-in-time grants with session recording. Sequence it so you do not blind yourself — the same access frequently runs your patching and monitoring, so agree a break-glass path with the provider before you pull it.