Skip to main content
Tier One
High

New cloud access key created for a service principal

A-1061

00:00time on this alert, target 10 minutes

Back to queue

Alert details

Source
Cloud Audit Log
Detection rule
CLOUD-IAM-KEY-CREATE-002
Affected user
dtanaka
Affected host
LAPTOP-DTANAKA
Source IP
103.114.161.7
First seen
2026-07-24T16:41:00Z

Why this fired, in plain English

A long-lived access key was created in the cloud account. Keys like this let someone in without a password or MFA.

Suggested playbook

Privilege escalation

  1. 1. Establish scope: local group (4732) or domain group (4728)?
  2. 2. Check for an approved change ticket or helpdesk ticket covering the grant.
  3. 3. Check whether the rights were later removed (4733/4729) — clean-up suggests legitimate work.
  4. 4. Identify who performed the action and from which host and IP.
Open the full checklist

Raw log evidence

Exactly what the tools recorded — 3 events.

  1. Guided hint: this line matters

    ts=2026-07-24T16:40:11Z src="cloud_audit" event=CreateAccessKey actor="dtanaka@northwind-mfg.example" target_principal="sp-reporting-prod" src_ip=103.114.161.7 user_agent="python-requests/2.31.0"

    The same Singapore IP and scripted user agent seen in the earlier mailbox compromise.

  2. Guided hint: this line matters

    ts=2026-07-24T16:40:19Z src="cloud_audit" event=AttachRolePolicy actor="dtanaka@northwind-mfg.example" principal="sp-reporting-prod" policy="AdministratorAccess"

    AdministratorAccess grants full control of the cloud tenant.

  3. Guided hint: this line matters

    ts=2026-07-24T16:40:52Z src="cloud_audit" event=ConsoleLogin principal="sp-reporting-prod" auth_type="access_key" mfa=false src_ip=103.114.161.7 result=Success

Related events

The order things happened in.

  1. 16:40Z

    Access key created for a service principal

  2. 16:40Z

    AdministratorAccess attached

  3. 16:40Z

    Key used to sign in without MFA

Enrichment lookups

Mock lookups. Run each one yourself — a real analyst never guesses what a lookup would have said. There is no "run everything" button on purpose.

0 of 3 lookups checked

  • Not checked yet.

  • Not checked yet.

  • Not checked yet.

Part of incident INC-2201

Account takeover of dtanaka — Singapore VPN

Three separate alerts fired across the shift. On their own each looks survivable. Together they are one intrusion: stolen password, MFA bypassed, mailbox looted, then cloud persistence.

What links them: Source IP 103.114.161.7 and the user dtanaka appear in all three.

  1. 1 · Credential access

    Correct password from Singapore, 11 MFA pushes denied. The password was already stolen.

    Open A-1071
  2. 2 · Impossible travel & collection

    Same IP finally signs in without MFA, creates a hidden inbox rule and reads 284 messages.

    Open A-1047
  3. 3 · Cloud persistence

    Same IP creates a long-lived access key on an admin service principal — access that survives a password reset.

    A-1061 — you are here

Tier 1 work is not just judging one alert. When the same user, host or IP shows up twice in a shift, link the tickets — the severity of the chain is always higher than the severity of its parts.

techniques

Your verdict

Keyboard shortcuts 1–4, or click. You can always change your mind afterwards.