Most SOCs have a few identity detections per platform, written at different times by different people, with gaps exactly where attackers go: new federation trusts, credentials added to applications, MFA removed and keys minted for service accounts. This guide is a consolidated starter pack of identity detections that should exist in any organisation running Microsoft Entra ID, Okta, AWS or Google Cloud and Workspace. Each rule names the log source, the exact event or field, the ATT&CK technique and the matching public Sigma rule where one exists, so a detection engineer can implement it in any SIEM. It is written for detection engineers, identity security teams and SOC leads. For depth on a single platform, use the Entra ID Sign-In and Audit Log Detection Guide, Okta System Log Detection Guide, AWS CloudTrail Guide and Google Workspace Audit Log Detection Guide.
Key takeaways
- Control-plane changes first. New identity providers, federation settings, admin role grants and MFA changes are rare, high-signal and cheap to alert on. Build them before behavioural sign-in analytics.
- Treat credential creation as an alert. A secret added to an Entra app, an AWS access key created for another user, a Google Cloud service account key or an Okta API token is how attackers persist without a password.
- Use the same rule across platforms. "MFA removed from an account" exists in all four; one rule definition with four mappings keeps coverage honest.
- Enable the logs before you write the rules. Entra service principal sign-ins, Google Cloud Data Access logs and Okta System Log retention beyond the default all have to be switched on or exported.
- Use vendor risk signals, but do not depend on them. Entra ID Protection and Google's suspicious login classifications are useful inputs, and several require premium licences.
How the pack is organised
Rules are grouped into six detection themes. Each theme has an equivalent rule per platform. Priority 1 rules are low volume and should page someone; priority 2 rules go to a triage queue; priority 3 are hunting or correlation inputs. Sigma rule names refer to the public SigmaHQ repository, which gives vendor-neutral logic that converts to most SIEM query languages. See the Sigma Rules Guide.
| Theme | What it catches | Main ATT&CK techniques |
|---|---|---|
| A. Identity provider and trust changes | New IdP, federation or directory trust that lets an attacker mint identities | T1484.002 Trust Modification, T1556 Modify Authentication Process |
| B. Privilege grants | Admin roles and high-privilege permissions added to users, groups or apps | T1098.003 Additional Cloud Roles |
| C. Credentials added to identities | Secrets, keys, tokens and certificates created for existing identities | T1098.001 Additional Cloud Credentials |
| D. Authentication weakening | MFA removed or reset, policies loosened, temporary passes issued | T1556.006 Multi-Factor Authentication |
| E. Suspicious sign-in | Spray, MFA-less sign-in, anonymising proxies, legacy and device code flows | T1110.003 Password Spraying, T1078.004 Cloud Accounts, T1621 MFA Request Generation |
| F. Logging and defence impairment | Audit trails stopped or altered | T1685.002 Disable or Modify Cloud Log |
Microsoft Entra ID rules
Sources: Entra audit logs, interactive and non-interactive sign-in logs, service principal and managed identity sign-in logs, and ID Protection risk detections, exported to your SIEM through diagnostic settings.
| ID | Rule | Event or field | Priority | Sigma reference |
|---|---|---|---|---|
| ENT-A1 | Domain federation changed | Audit activity "Set federation settings on domain" | 1 | Azure Domain Federation Settings Modified |
| ENT-B1 | User added to privileged role | Audit "Add member to role" for Global Administrator and other Tier 0 roles | 1 | User Added to an Administrator's Azure AD Role |
| ENT-B2 | App granted privileged application permission | Audit "Add app role assignment to service principal" | 1 | App Granted Privileged Delegated Or App Permissions |
| ENT-B3 | Tenant-wide delegated consent | Audit "Consent to application" with admin consent for all users | 2 | Delegated Permissions Granted For All Users |
| ENT-C1 | Secret or certificate added to an app | Audit "Update application - Certificates and secrets management" | 1 for privileged apps, 2 otherwise | Added Credentials to Existing Application |
| ENT-D1 | Temporary Access Pass issued | Audit "Admin registered security info" with temporary access pass method | 2 | Temporary Access Pass Added To An Account |
| ENT-D2 | Conditional Access policy changed by an unapproved actor | Audit add, update or delete conditional access policy, actor not in approved list | 1 | CA Policy Updated by Non Approved Actor |
| ENT-E1 | Legacy authentication sign-in | Sign-in ClientApp IMAP, POP3, SMTP, MAPI, Exchange ActiveSync or "Other client" | 2 | Use of Legacy Authentication Protocols |
| ENT-E2 | Device code flow sign-in | Sign-in authentication protocol device code, outside approved device types | 2 | Application Using Device Code Authentication Flow |
| ENT-E3 | ID Protection high-risk detection | Risk detections such as Password spray, Anomalous token, Token issuer anomaly, Leaked credentials | 2 | Vendor signal |
| ENT-E4 | Workload identity risk | servicePrincipalRiskDetections: suspiciousSignins, leakedCredentials, suspiciousAPITraffic | 2 | Vendor signal |
Microsoft documents that Password spray, Anomalous token and Token issuer anomaly require Entra ID P2, that Leaked credentials is available at Free and P1, and that all eight workload identity detections are offline, with full detail and risk-based Conditional Access requiring Workload Identities Premium. Midnight Blizzard's 2024 intrusion at Microsoft began with a password spray against a legacy test tenant account without MFA and moved through OAuth applications granted the Exchange full_access_as_app role, which rules ENT-B2 and ENT-C1 are designed to catch. See the Microsoft Midnight Blizzard Breach 2024.
Okta rules
Source: Okta System Log (LogEvent objects), pulled through the System Log API or a log streaming integration into your SIEM.
| ID | Rule | eventType | Priority | Sigma reference |
|---|---|---|---|---|
| OKT-A1 | New identity provider created | system.idp.lifecycle.create | 1 | Okta Identity Provider Created |
| OKT-B1 | Admin role granted to user or group | user.account.privilege.grant, group.privilege.grant | 1 | Okta Admin Role Assigned to an User or Group |
| OKT-C1 | API token created | system.api_token.create | 1 | Okta API Token Created |
| OKT-D1 | MFA factor deactivated or all factors reset | user.mfa.factor.deactivate, user.mfa.factor.reset_all | 2 (1 for admins) | Okta MFA Reset or Deactivated |
| OKT-D2 | Policy or policy rule changed | policy.rule.update, policy.rule.delete and policy lifecycle events | 2 | Okta Policy Rule Modified or Deleted |
| OKT-D3 | Network zone deactivated or deleted | Network zone lifecycle events | 2 | Okta Network Zone Deactivated or Deleted |
| OKT-E1 | Session from anonymising proxy | user.session.start where securityContext.isProxy is true | 2 | Okta User Session Start Via An Anonymising Proxy Service |
| OKT-E2 | Okta threat detection | Security threat detected events | 2 | Okta Security Threat Detected |
| OKT-E3 | User reports suspicious activity | End-user suspicious activity report event | 2 | Okta Suspicious Activity Reported by End-user |
The attackers in the 2023 MGM Resorts intrusion said they reached Okta and Azure administrator access after social engineering the help desk; the lessons drawn on the MGM Resorts Breach 2023 page are to alert on new admins, MFA resets and new federation, which are OKT-B1, OKT-D1 and OKT-A1.
AWS rules
Source: an organisation CloudTrail trail delivering management events from every account and region, with IAM Identity Center events.
| ID | Rule | Event or field | Priority | Sigma reference |
|---|---|---|---|---|
| AWS-A1 | Identity Center identity source changed | EnableExternalIdPConfigurationForDirectory, DisableExternalIdPConfigurationForDirectory, AssociateDirectory, DisassociateDirectory | 1 | AWS Identity Center Identity Provider Change |
| AWS-A2 | SAML provider deleted or changed | IAM SAML provider events | 1 | AWS SAML Provider Deletion Activity |
| AWS-B1 | Root user activity | userIdentity.type = Root, excluding AwsServiceEvent | 1 | AWS Root Credentials |
| AWS-C1 | Access key created for another user | CreateAccessKey where the caller is not the key's user | 1 | AWS IAM Backdoor Users Keys |
| AWS-C2 | Console password added or changed for a user | Login profile create or update | 2 | AWS User Login Profile Was Modified |
| AWS-E1 | Console sign-in without MFA | ConsoleLogin, additionalEventData.MFAUsed = No, responseElements.ConsoleLogin = Success, for IAM and root users | 2 | AWS Successful Console Login Without MFA |
| AWS-E2 | Instance role credentials used outside AWS | Assumed-role sessions from EC2 instance profiles with a non-AWS source IP | 1 | Malicious Usage Of IMDS Credentials Outside Of AWS Infrastructure |
| AWS-F1 | CloudTrail stopped or changed | StopLogging, UpdateTrail, DeleteTrail | 1 | AWS CloudTrail Important Change |
AWS documents that MFAUsed is set only for IAM and root users who sign in with MFA, and that federated sign-ins show No, so scope AWS-E1 to IAMUser and Root identity types to avoid flooding the queue with Identity Center sessions. Root sign-ins are recorded in us-east-1, us-east-2 or us-west-2, so collect all regions.
Google Cloud and Google Workspace rules
Sources: Cloud Audit Logs (Admin Activity, plus Data Access where enabled) routed through an organisation log sink, and Workspace admin and login audit logs exported to Cloud Logging or your SIEM. See the Google Cloud Audit Logs and Log Sinks Guide.
| ID | Rule | Event or method | Priority | Sigma reference |
|---|---|---|---|---|
| GCP-B1 | IAM policy changed at organisation or folder | SetIamPolicy on organisations and folders adding owner, editor or IAM admin roles | 1 | None: build locally |
| GCP-C1 | Service account key created or uploaded | google.iam.admin.v1.CreateServiceAccountKey, google.iam.admin.v1.UploadServiceAccountKey | 1 where keys are blocked by policy, 2 otherwise | Partial: Google Cloud Service Account Modified |
| GCP-C2 | Service account created or re-enabled | Methods ending .serviceAccounts.create, .enable, .undelete | 3 | Google Cloud Service Account Modified |
| GWS-B1 | Admin privilege granted | Admin log GRANT_ADMIN_PRIVILEGE, GRANT_DELEGATED_ADMIN_PRIVILEGES | 1 | Google Workspace User Granted Admin Privileges |
| GWS-B2 | Domain-wide delegation granted | Admin log AUTHORIZE_API_CLIENT_ACCESS | 1 | Google Workspace Granted Domain API Access |
| GWS-D1 | 2-Step Verification enforcement changed | Admin log ENFORCE_STRONG_AUTHENTICATION, ALLOW_STRONG_AUTHENTICATION | 1 | Google Workspace MFA Disabled |
| GWS-E1 | Google-classified suspicious login | Login log suspicious_login, suspicious_login_less_secure_app, suspicious_programmatic_login | 2 | Suspicious Login Activity Classified By Google |
| GWS-E2 | Government-backed attack warning | Login log gov_attack_warning | 1 | Google Workspace Government Attack Warning |
| GWS-E3 | Out-of-domain mail forwarding | Login log email_forwarding_out_of_domain | 2 | Google Workspace Out Of Domain Email Forwarding |
Google documents service account key creation and SetIAMPolicy as Admin Activity (ADMIN_WRITE) events, while reads such as ListServiceAccountKeys are Data Access (ADMIN_READ) events that must be enabled before they can be detected. Domain-wide delegation is covered in depth in the Google Workspace Domain-Wide Delegation Security Guide.
Cross-platform correlations
Single events miss chains that span the IdP and the cloud. Build these as correlation rules once the single-event rules are stable.
- Weakening then use: MFA removed or a Temporary Access Pass issued (ENT-D1, OKT-D1), followed within 24 hours by a sign-in from a new country or ASN for the same user.
- Grant then credential: an admin role or high-privilege permission granted (any B rule) followed by a credential created for an application or service account (any C rule) by the same actor.
- Federation then admin sign-in: a new IdP or federation change (any A rule) followed by an admin sign-in whose issuer or identity source is the new one.
- IdP compromise to cloud: Okta or Entra admin role change followed by AWS Identity Center or Google Cloud IAM changes from a federated session for the same person.
- Impair then act: any F rule followed by B or C rules in the same account within an hour.
Rolling out the pack
- Confirm log coverage: Entra sign-in categories including service principal and managed identity sign-ins, Okta System Log export, organisation CloudTrail across all regions, Google Cloud organisation sink and Workspace audit export. Measure ingestion lag for each.
- Build an allow list of expected actors: identity admins, provisioning service principals and automation roles that legitimately make A to D changes. Most false positives come from these.
- Deploy priority 1 rules in alert mode with a two-week tuning window, then route to on-call.
- Test each rule: perform the action in a test tenant or account and confirm the alert fires end to end. See the Detection Validation and Testing Guide.
- Deploy priority 2 rules to a triage queue and priority 3 to hunting dashboards.
- Write a runbook per rule: what to check, who owns the identity, how to contain. The Detection Rule Documentation Template gives the format.
- Store rules as code with tests and version control so changes are reviewed. See the Detection as Code Guide.
Decision guidance
- Vendor ITDR or SIEM rules: ITDR products ship many of these detections and add behavioural baselines. Keep the priority 1 control-plane rules in your SIEM regardless, so that a gap in the product's coverage or licence does not leave you blind.
- Small teams: implement themes A, B, C and F only. They are low volume and catch most persistence. Add E when you have someone to triage sign-in alerts.
- Large or multi-tenant estates: parameterise rules by tenant or account and maintain one allow list per environment; centrally owned Tier 0 role lists keep B rules consistent.
- Licensing: if you lack Entra ID P2 or Workload Identities Premium, compensate with sign-in log rules (ENT-E1, ENT-E2) and credential creation rules, which need no premium signal.
Measuring the pack
| Metric | How to measure |
|---|---|
| Coverage | Rules deployed per platform against the pack, and ATT&CK techniques covered |
| Validated rules | Share of rules with a passing end-to-end test in the last 90 days |
| Signal quality | True positive or benign-confirmed rate per rule; priority 1 rules should rarely be noise |
| Time to detect | Event time to alert time, including log ingestion lag |
| Allow list hygiene | Allow list entries reviewed in the last quarter |
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-03, DE.AE-02 | Monitoring personnel activity and technology usage; analysing adverse events |
| NIST SP 800-53 Rev. 5 | AU-6, AU-12, SI-4, AC-2(4) | Audit review, audit record generation, system monitoring, automated audit of account actions |
| CIS Controls v8.1 | Safeguards 8.2, 8.11 | Collect audit logs; conduct audit log reviews |
| MITRE ATT&CK | T1484.002, T1098.001, T1098.003, T1556.006, T1110.003, T1078.004, T1685.002 | Techniques the pack detects |
Common failure patterns
- No service principal sign-in logs: Entra diagnostic settings export each sign-in category separately; selecting only user sign-ins leaves service principal and managed identity abuse unseen.
- Allow lists that swallow the attack: excluding every identity admin from B rules means a compromised admin raises nothing. Allow list automation identities, not people.
- AWS-E1 without identity type scoping: every federated console session appears as "no MFA" and the rule is muted within a week.
- Single-region CloudTrail: root and IAM sign-in events land in specific regions and are missed.
- Relying only on vendor risk scores: offline detections arrive hours later and some need licences you may not hold.
- Rules that are never tested: log schema and field names change, and a rule that has not fired in a year may simply be broken.
Practitioner checklist
- Confirm all identity log sources are exported, all regions and all sign-in categories, and measure ingestion lag.
- Deploy every priority 1 rule (A, B, C, F themes) on each platform you run.
- Maintain allow lists of automation identities, reviewed quarterly.
- Scope noisy rules by identity type, application or role tier rather than disabling them.
- Test every rule end to end in a non-production tenant and re-test every 90 days.
- Write a short runbook per rule naming the identity owner and containment action.
- Add the five cross-platform correlations once single-event rules are stable.
- Track coverage, validation and signal quality per rule.
Standards and references
- Microsoft Learn: What are risk detections
- Microsoft Learn: Securing workload identities with ID Protection
- Okta Developer: Event types
- AWS: AWS Management Console sign-in events in CloudTrail
- Google Cloud: IAM audit logging
- SigmaHQ: Sigma rule repository
- MITRE ATT&CK: Additional Cloud Credentials
- MITRE ATT&CK: Trust Modification
Related NHI Mgmt Group resources: ITDR Guide · Detection Engineering for Non-Human Identities Guide · Identity Visibility, Posture and Threat Detection Guide · Identity Incident Response Playbook