Service Accounts With Standing Administrative Privileges

Service accounts — non-human identities used by applications, scheduled tasks, agents, integrations — hold standing administrative privileges, often at the broadest possible level: directory administration, backup platform administration, fleet-wide administration.

This is structural: when a product is deployed, granting maximum privilege is the path that “works on the first try,” and installation documentation sometimes asks for it explicitly. No one comes back afterward to scale it down, because the account “belongs” to the application, not to a person — it falls outside the access reviews designed for humans, outside departures, outside recertifications. On top of this come inherently aggravating properties: an old secret that’s rarely rotated (rotation breaks things), MFA that cannot be applied, and legitimate activity that is automated, high-volume, and runs at night — perfect camouflage.

These accounts are a priority target for privilege escalation: their secrets can be harvested — from the memory of the machines they run on, from configuration files, from scheduled task definitions — and their malicious use blends into their normal activity. A service account connecting to forty machines overnight is normal: that’s its job. The same pattern, produced by an attacker, doesn’t stand out.

Two specific consequences during an incident:

• behavioral detection is weakened precisely on the most powerful accounts: their “normal” activity baseline is so broad that almost anything resembles it;
• remediation is painful: rotating the secret of an administrative service account breaks the applications that depend on it — dependencies no one has documented. Rotation is therefore deferred during the incident itself, leaving the attacker with privileged access that the entire team knows about and no one dares to shut down.

Start from the directory, not from the declarative inventory:

• extract the members of administrative groups and isolate the non-human ones: naming convention, absence of interactive logon, password age;
• for each one: who can explain what it does? what rights does it actually need — often precise rights on precise objects, not global administration? when was its secret last changed? from which machines does it legitimately connect?

The account that no one can explain but no one dares touch is the signature of this pattern — record it as such in the findings.

Supplement this with a hunt for exposed secrets: service account passwords in plaintext in scripts, configuration files, task definitions — every occurrence is a collection point handed to the attacker.

Four workstreams, in order of payoff:

• inventory with an owner: every service account has a named owner, a documented function, and a list of the systems that depend on it — it’s this list that makes rotation possible on the day it becomes urgent;
• reduction to actual privilege: delegate precise rights rather than membership in administrative groups; most products work with less than what their installation guide asks for;
• tooled rotation: a secrets vault, or platform-managed service accounts where the identity platform supports it — a rotation that breaks nothing is one that can be done often;
• restriction and detection: a service account connects from its own machines, to its own targets; an interactive logon with such an account is an alert, not an event. And no privileged service account is created without review.

Privileged service accounts fall within scope by default:

• review their activity over the compromise window looking for deviations from routine: new target machines, interactive logons, unusual hours, actions outside their function — since the routine is broad, it’s the deviations that speak;
• cut off what the account can do first, rotate second: immediately restrict the account’s allowed network origins, remove rights not needed for its function, block its interactive logon, and enable granular logging. These steps are reversible and don’t break unknown dependencies;
• secret rotation follows, planned with the application team — but it no longer gates containment. An imperfect restriction right now beats a perfect rotation twelve hours from now;
• after rotation, check the logs to confirm the old secret is no longer used anywhere: repeated authentication failures reveal both a forgotten dependency and, sometimes, an attacker trying again.