How to Detect Service Account Misuse: Per-Platform Queries, Baselines and Triage

A misused service account looks like a working one: every request is authenticated, authorised and logged as the account, so detection depends on knowing exactly what that account normally does and writing queries that notice when it does something else. This guide turns that idea into a working detection set across Active Directory, Microsoft Entra ID, AWS, Google Cloud and Kubernetes: which log fields carry the signal on each platform, the query logic for each rule, how to roll the rules out without drowning the SOC, and how to triage a hit. It is written for detection engineers and SOC analysts who already collect these logs. The theory of which behaviours to baseline is covered in the Service Account Behavioural Baselining Guide, and console or Remote Desktop use of a service account has its own runbook in How to detect interactive logons by service accounts. This page is the query layer for non-interactive misuse.

Key takeaways

• Join every query to an inventory. A rule that knows which identities are service accounts, who owns them and where they should run is far more precise than one that guesses from names.
• Use the credential and source fields first. Each platform records which key or certificate was used and where the call came from; a known identity using an unusual credential from a new network is the strongest single signal.
• First-seen beats thresholds. Rules that fire on a new API, resource, namespace, service or Kerberos target for a given account catch reconnaissance before data moves.
• Turn on the native detections, then fill their gaps. Cloud providers already baseline some workload identities; your queries should cover what they exclude, such as managed identities and on-premises accounts.
• Every hit needs an owner answer. Route alerts to the account owner as well as the SOC, so each one ends as a confirmed change, a policy violation to fix or an incident.

What misuse looks like

Misuse comes from attackers with stolen or added credentials and from people using a service account for something it was not created for. Both leave the same patterns.

Before you start

1. Build the watchlist. For each service account record a stable identifier (SID, object ID, role ARN, service account email, Kubernetes namespace and name), owner, purpose, expected hosts or networks and expected credentials. For Active Directory, the How to build a service account inventory from Active Directory guide gives the method.
2. Confirm the logs arrive. Check each source below reaches your SIEM from every region, subscription, project and cluster the accounts use. Missing regions are where attackers go.
3. Feed change context. Bring deployment and change records into the SIEM so a new API call after a release can be matched to that release.
4. Agree the learning window. Thirty days captures monthly jobs; review privileged accounts by hand first so an attacker already present is not learned as normal.

Signal fields by platform

Platform notes that change query design:

• Entra ID: managed identities have their own sign-in log category; build the same rules against it as well as the service principal log.
• AWS: CloudTrail's userIdentity.type separates long-term IAM user keys (IAMUser) from role sessions (AssumedRole). For role sessions, baseline on the session issuer ARN, because the session name changes. AWS notes that accessKeyId may be absent or empty.
• Google Cloud: serviceAccountKeyName shows which user-managed key signed the request, and serviceAccountDelegationInfo records the impersonation chain, so a call by a service account can be traced to the person or workload that impersonated it. Check that Data Access audit logs are enabled for services where the account touches sensitive data.
• Kubernetes: auditing needs an audit policy file and a backend on the API server (--audit-policy-file with --audit-log-path or a webhook). Managed services expose it through their own logging settings. Log at least Metadata level for secrets, so values are never written to the audit log.

Detection rules and query logic

Each rule below is written as logic with the fields above. Translate it into your SIEM's language and confirm column names in your own workspace: connectors and normalisation differ.

Active Directory: service account requesting unusual Kerberos tickets

A domain service account normally requests tickets for a small, fixed set of services from a small set of hosts. Microsoft's own monitoring guidance for event 4769 recommends alerting when an account requests tickets for services it should never access and when the Client Address is outside an allow list.

4769 where Account Name in ServiceAccountWatchlist
  and Failure Code == 0x0
summarise first_seen by Account Name, Service Name, Client Address over 30 days
alert when (Account Name, Service Name) pair is new
   or (Account Name, Client Address) pair is not in the account's expected hosts
raise severity when Service Name is a domain controller, an administrative service or a file server holding sensitive shares

Add Ticket Encryption Type: Microsoft recommends monitoring for anything other than 0x11 and 0x12 (AES), because RC4 (0x17) requests for a service account can indicate ticket requests intended for offline cracking. See the Kerberoasting and AS-REP Roasting Defence Guide for that case.

Entra ID: service principal from a new network or with an unusual credential

AADServicePrincipalSignInLogs
| where ResultType == "0"
| where ServicePrincipalId in (watchlist)
| summarize first_seen = min(TimeGenerated) by ServicePrincipalId, IPAddress, AutonomousSystemNumber, ServicePrincipalCredentialKeyId, ResourceDisplayName
| where first_seen > ago(1d)

Alert when any of the four dimensions is new for the service principal; weight a new credential key ID highest, because an attacker who added a secret signs in with a key the application has never used. Run the same logic against the managed identity sign-in table. See the How to rotate Entra app secrets without downtime guide for containing a confirmed hit.

AWS: role or key behaving out of pattern

CloudTrail where identity_key = coalesce(sessionContext.sessionIssuer.arn, userIdentity.arn)
  and identity_key in watchlist
rule A: sourceIPAddress not in expected ranges and vpcEndpointId is empty and userIdentity.type == "AssumedRole"
rule B: first_seen(identity_key, eventSource, eventName) in last day
        and eventName matches List*, Get*Policy*, GetCallerIdentity, CreateAccessKey, PutUserPolicy, AttachRolePolicy
rule C: first_seen(identity_key, awsRegion) in last day
rule D: count(errorCode == "AccessDenied") per identity_key per hour above its 99th percentile
rule E: userAgent family changes (SDK to CLI or console) for a workload identity

Rule A overlaps with the GuardDuty findings UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS and .InsideAWS, which flag EC2 instance credentials used from outside AWS or from another AWS account. Keep your own version for roles assumed by containers, functions and CI/CD, which those findings do not describe. The How to Investigate CloudTrail for a Compromised Access Key guide covers the follow-up.

Google Cloud: keys, impersonation and first-seen methods

Audit logs where principalEmail ends with ".gserviceaccount.com" and principalEmail in watchlist
rule A: serviceAccountKeyName is present and the key is not in the account's approved key list
rule B: callerIp is new for the account and not a Google internal or expected range
rule C: serviceAccountDelegationInfo shows a principal not approved to impersonate this account
rule D: first_seen(principalEmail, serviceName, methodName) in last day, priority for SetIamPolicy, CreateServiceAccountKey, GenerateAccessToken

Rule A is valuable where keys should not exist at all: any key-signed request from an account meant to use attached identities or impersonation is a finding. For who may impersonate whom, see How to Audit GCP Service Account Impersonation Rights.

Kubernetes: service account tokens used outside their pod

Audit events where user.username starts with "system:serviceaccount:"
rule A: sourceIPs not in pod or node CIDRs for the cluster
rule B: verb in (get, list, watch) and objectRef.resource == "secrets" and first_seen for this account
rule C: verb == "create" and objectRef.resource in (pods, pods/exec, serviceaccounts/token, rolebindings, clusterrolebindings)
rule D: userAgent changes from the application's client library to kubectl

Rule A is the clearest sign of a stolen token. Rules B and C map to escalation routes the Kubernetes RBAC good practices page lists: reading secrets, creating workloads, requesting service account tokens and creating bindings. See the Kubernetes Audit Log Detection Guide for broader cluster rules.

Native detections and their gaps

Enrich native findings from the watchlist in the same queue. See the Amazon GuardDuty Guide and Microsoft Entra ID Protection for configuration.

Rolling the rules out

1. Week 1 to 2, report mode: deploy all rules without paging. Label each hit as malicious, policy violation (a person using the account), undocumented change or inventory error.
2. Fix the inventory, not the rule: most early hits are wrong expected hosts or networks. Update the watchlist with an owner's confirmation.
3. Exclude narrowly: suppress specific account, source and action combinations with a ticket reference and an expiry, never a whole host, subnet or account.
4. Promote rules one at a time: start with the credential and source rules (new key, token off-cluster, credentials off-platform), which have the best precision, then first-seen discovery, then volume.
5. Test continuously: run scheduled, authorised tests with a dedicated test service account on each platform (a sign-in from an unexpected network, a first-seen discovery call) and alert if the rule does not fire. Treat rules as code: see the Detection as Code Guide.
6. Roll back: if a rule floods the queue, return it to report mode rather than deleting it.

Triage a hit

• Change match: is there a deployment, migration or approved change for this account in the window? If yes and the owner confirms, update the baseline.
• Credential: which key, secret, certificate or token was used, when was it created, by whom, and is it stored where it should be?
• Source: is the address a corporate network, a CI provider, a cloud provider you use, a hosting provider you do not, or a residential range?
• Breadth: what else did the same credential or source do in the past 30 days, on every platform?
• Person or attacker: a known administrator using the account is still a finding (human use of a non-human identity), handled through the owner. See the OWASP NHI Top 10 NHI10 Human Use of NHI Guide.
• Contain if unexplained: disable the specific credential, revoke active sessions where the platform supports it, look for credentials added by the same actor, then rotate. The Workload Identity Compromise Response Playbook covers the full response.

Detection and measurement

• Coverage: percentage of service accounts on the watchlist with an owner, expected sources and at least one active rule, per platform.
• Log completeness: percentage of regions, subscriptions, projects and clusters that send the source logs above to the SIEM.
• Precision: share of hits per rule labelled malicious or policy violation, reviewed monthly.
• Test pass rate: share of scheduled test events that produced an alert within the expected time.
• Time to contain: median time from first anomalous event to credential disabled, from incidents and exercises.
• Human-use findings: count per month, which should fall as owners move people to named accounts.

Common failure patterns

• Baselining role sessions by session name: names change every session, so every call looks new. Key on the session issuer.
• Watching one plane: cloud rules with no Kerberos rules, or the reverse, miss attackers who move between them through sync accounts and federation.
• Trusting a native detection for every identity type: managed identities and on-premises accounts fall outside the provider models.
• Suppressing whole networks: excluding the CI provider's ranges hides an attacker running from the same provider with a stolen pipeline token.
• Kubernetes audit not enabled or set too low: without an audit policy the API server records nothing, and the token rules have no data.

Framework mapping

Practitioner checklist

• Service account watchlist with stable IDs, owners, expected sources and expected credentials for every platform.
• Kerberos 4769, Entra service principal and managed identity sign-ins, CloudTrail in all regions, Cloud Audit Logs with Data Access where needed, and Kubernetes audit logs all reaching the SIEM.
• Credential and source rules live on every platform: new key or certificate, new network, token used off-cluster.
• First-seen rules for discovery, IAM changes, new regions and new Kerberos targets.
• GuardDuty and ID Protection workload identity detections enabled and enriched from the watchlist.
• Suppressions scoped to account, source and action with expiry and ticket.
• Scheduled authorised tests prove each rule still fires.
• Alerts routed to the account owner as well as the SOC, with containment steps agreed in advance.

Standards and references

• NIST: SP 800-53 Rev. 5 (AC-2(12) Account Monitoring for Atypical Usage)
• Microsoft Learn: 4769(S, F) A Kerberos service ticket was requested
• Microsoft Learn: AADServicePrincipalSignInLogs table reference
• Microsoft Learn: Securing workload identities with ID Protection
• AWS: CloudTrail userIdentity element
• AWS: GuardDuty IAM finding types
• Google Cloud: AuditLog reference
• Kubernetes: Auditing

Related NHI Mgmt Group resources: Service Account Behavioural Baselining Guide · How to detect interactive logons by service accounts · Detection Engineering for Non-Human Identities Guide · UEBA Guide · How to find service accounts with Domain Admin rights