Skip to main content
ORDRANISecurity

Use cases

How machine identity threats unfold — and how they are investigated.

The scenarios below describe realistic ways in which automated identities are compromised or misused, the behavioral signals that reveal them, and how Ordrani helps a security team reach a decision.

Scenarios

  1. 01

    Compromised service account

    A long-lived credential is copied out of a build environment and used elsewhere.

  2. 02

    Unusual cloud role activity

    A role begins exercising permissions it has always held but never needed.

  3. 03

    Automated deployment workflow misuse

    A pipeline with production access is run from an unexpected branch with an altered workflow.

  4. 04

    Suspicious machine-to-machine access

    A service forms a relationship with a system it has no functional reason to reach.

  5. 05

    Unexpected access to sensitive resources

    Automation reads secrets, keys or data stores outside its function.

  6. 06

    Cross-system privilege misuse

    Privilege gained in one system is exercised in another.

Threat scenarios in detail

01Scenario

Compromised service account

A long-lived credential is copied out of a build environment and used elsewhere.

The scenario

A backup service account holds an access key with read access to several storage buckets and permission to describe infrastructure. The key is exposed in a build log and copied by an attacker, who uses it from their own infrastructure.

Every request the attacker makes is signed with a valid key. Nothing about an individual call is malformed or forbidden.

Event sequence

  1. nightly backup (normal)
  2. new source network · 03:14
  3. ec2:Describe* ×120
  4. s3:ListBuckets

Behavioral signals

  • API calls from a network and user agent never associated with the identity
  • Activity outside the account’s fixed nightly schedule
  • Describe and list operations across services the account has never queried
  • Concurrent use from two distinct execution contexts

How Ordrani approaches it

Because the service account’s behavior is highly regular, Ordrani’s behavior model for it is tight. Activity outside its schedule, from a new context, touching new services, departs from that model on several independent dimensions at once.

The case presents the divergence side by side with the baseline, identifies the first anomalous event, and lists every resource the credential reached since — giving responders the scope they need to decide on rotation.

Analysts see exactly when the credential diverged from its routine and what it touched afterward.

02Scenario

Unusual cloud role activity

A role begins exercising permissions it has always held but never needed.

The scenario

A monitoring role was granted broad read permissions years ago for convenience. For months it has used a narrow subset to collect metrics. One afternoon it begins enumerating IAM users, roles and attached policies.

Permission reviews would show nothing new; the role has always been allowed to do this. The change is in behavior, not entitlement.

Event sequence

  1. cloudwatch:GetMetricData
  2. iam:ListUsers
  3. iam:ListAttachedRolePolicies
  4. sts:AssumeRole → admin-role

Behavioral signals

  • First use of IAM read operations by this identity
  • Sharp increase in the breadth of resources described
  • Activity inconsistent with the role’s companion identities and services

How Ordrani approaches it

Ordrani tracks permission utilization — the portion of granted permissions an identity actually exercises. Movement into the dormant portion of a role’s permissions is a strong signal, particularly when it involves identity or security configuration.

If the enumeration is followed by a role assumption or policy change, the deviations are correlated into a single sequence and the case’s priority rises accordingly.

A role’s dormant permissions become visible as a risk — and their first use becomes an event worth reviewing.

03Scenario

Automated deployment workflow misuse

A pipeline with production access is run from an unexpected branch with an altered workflow.

The scenario

A deployment workflow federates into a production AWS role through OIDC. An attacker with write access to the repository pushes a branch that modifies the workflow file, adding steps that use the role’s session to read secrets and create a new access key.

If the role’s trust policy is broader than intended — accepting any branch rather than only the protected one — the cloud provider will issue credentials without complaint.

Event sequence

  1. push · feature/x
  2. deploy.yml modified
  3. AssumeRoleWithWebIdentity
  4. GetSecretValue
  5. iam:CreateAccessKey

Behavioral signals

  • OIDC subject claim referencing a non-protected branch
  • Workflow definition changed in the same push that triggered the run
  • Operations outside the deployment’s historical scope: secret reads, key creation
  • Run duration and step count inconsistent with prior deployments

How Ordrani approaches it

The Workflow Provenance Engine links the role session to the specific repository, ref and run. With that context, Ordrani can see that the session originated from an unusual branch and that its operations fall outside what this workflow has ever done.

The case points engineering directly to the commit, workflow revision and run responsible, and flags the trust policy condition that allowed it.

Responders know which run, commit and trust condition to act on — within minutes of the activity.

04Scenario

Suspicious machine-to-machine access

A service forms a relationship with a system it has no functional reason to reach.

The scenario

A customer-notification service runs in a container with a workload identity permitted to call a messaging API and read a configuration store. After a vulnerable dependency is exploited, the workload’s identity is used to query a data store belonging to an unrelated billing service.

Both services operate in the same account, and the network path exists. The access is new rather than forbidden.

Event sequence

  1. sns:Publish (normal)
  2. new edge → billing-db
  3. dynamodb:Scan ×40

Behavioral signals

  • First-ever edge between the workload identity and the billing data store
  • Access pattern unlike any of the service’s established relationships
  • Request volume increasing over successive minutes

How Ordrani approaches it

The Temporal Identity Graph records which identities habitually interact with which resources. A new edge between previously unrelated systems is evaluated against the identity’s purpose and the sensitivity of the target.

Because the relationship is new, the case shows both the established graph and the new connection, so an analyst can see immediately how far the activity has departed from normal.

Unexpected service-to-service relationships are surfaced as they form, rather than discovered after data has moved.

05Scenario

Unexpected access to sensitive resources

Automation reads secrets, keys or data stores outside its function.

The scenario

A reporting job’s identity is permitted to read from a broad secrets path because of a wildcard in its policy. It normally retrieves a single API credential. It begins retrieving database credentials and decrypting data with a key it has not previously used.

Each retrieval is authorized; the wildcard made that inevitable. What matters is that the job has no reason to need them.

Event sequence

  1. GetSecretValue · reporting/api
  2. GetSecretValue · prod/db
  3. kms:Decrypt · new key

Behavioral signals

  • Retrieval of secrets outside the identity’s established set
  • First use of a KMS key by this identity
  • Sensitive-resource access soon after other behavioral deviations

How Ordrani approaches it

Ordrani weights deviations by the sensitivity of what they touch. A novel read of a public configuration file and a novel read of production database credentials are treated very differently.

Where the access follows other unusual activity by the same identity, the events are correlated, and the case lists each sensitive resource reached with the time it was first accessed.

Over-broad permissions stop being silent; their misuse is visible the first time it occurs.

06Scenario

Cross-system privilege misuse

Privilege gained in one system is exercised in another.

The scenario

An attacker compromises a third-party integration with write access to a source repository. They modify a workflow so that its next run, which federates into AWS, attaches an administrative policy to a role they can later assume.

The source control platform sees a routine commit. The cloud sees a deployment role modifying IAM. Neither system alone holds the full picture.

Event sequence

  1. integration commits workflow
  2. run → role session
  3. iam:AttachRolePolicy
  4. AssumeRole · new context

Behavioral signals

  • Commit from an integration identity to a workflow file
  • Deployment role performing IAM policy changes for the first time
  • Later assumption of the modified role from an unrecognized context

How Ordrani approaches it

Ordrani correlates source control events with the cloud activity they lead to. The commit, the run it triggered, the session that run created and the policy change made by that session form one connected sequence.

The resulting case spans both systems and explains the full path — from the integration that made the change to the privilege it ultimately created.

An attack that crosses system boundaries is investigated as one event, not two unrelated anomalies.

Anatomy of an investigation

What an analyst receives.

Each scenario ends in the same place: a single case that brings the timeline, attribution, affected assets and next steps together, so that the first question an analyst asks is answered before it is asked.

  • Expected and deviating operations distinguished at a glance
  • Attribution stated per event: confirmed or correlated
  • Assessment that names what remains unconfirmed
  • Response steps that require explicit approval

CASE OR-0142 · OPENED 14:42 UTC

Potential workflow identity misuse

Identity prod-deploy-role · origin deploy.yml #4182

High priorityAwaiting review

Reconstructed sequence

  1. 14:32:05

    sts:AssumeRoleWithWebIdentity

    org/payments-service · environment: production

    Confirmed
  2. 14:32:41

    ecs:UpdateService

    payments-api · task definition rev 212

    Confirmed
  3. 14:33:40

    iam:ListRoles, iam:ListPolicies

    37 calls in 52 s · first observed for this identity

    EnumerationConfirmed
  4. 14:36:12

    secretsmanager:GetSecretValue

    prod/db-credentials · classified sensitive

    Sensitive accessCorrelated
  5. 14:41:50

    iam:PutRolePolicy

    inline policy added to reporting-export-role

    Privilege changeCorrelated

Assessment

A deployment identity performed role enumeration it has never performed, then a sensitive secret was read by the same role after the run completed. The sequence is consistent with credential or workflow misuse. Authorization of the run has not been confirmed.

Affected assets

  • prod/db-credentials
  • reporting-export-role
  • payments-api (ECS)

Recommended next steps

  1. 1.Confirm with the repository owner whether run 4182 was an authorized deployment.
  2. 2.Review active sessions for prod-deploy-role and their source networks.
  3. 3.Inspect the inline policy added to reporting-export-role.
  4. 4.Revoke sessions and restrict the role trust policy — requires approval.

Have a scenario we should discuss?

If your team has encountered — or worries about — a pattern of machine identity misuse not covered here, we would like to hear about it.

Start a conversationPlatform overview