Use Case: Cloud & Identity
Privilege escalation detection
A developer account now has AdministratorAccess on AWS. The change took 30 seconds. The Jira ticket doesn't exist. ManySignal flagged it in 90.
The permission that shouldn't exist
Privilege escalation in cloud environments rarely looks like a movie hacking scene. It's a single AWS CLI call: aws iam attach-user-policy --user-name dev-build --policy-arn arn:aws:iam::aws:policy/AdministratorAccess. The call succeeds in 400ms. The user now has unrestricted access to every resource in the account. CloudTrail logs it. Nobody's watching CloudTrail.
In post-breach investigations, unauthorized privilege escalation is almost always discovered in hindsight — weeks after the attacker used the elevated access to create a backdoor IAM user, exfiltrate data from S3, or deploy a cryptominer in EC2. The escalation event itself was logged but never alerted on.
rule: privilege_escalation_cloud_iam
type: behavioral + itsm_correlation
sources:
- aws_cloudtrail
- azure_activity_log
- gcp_admin_activity
- okta_system_log
- active_directory_audit
trigger:
- event: [AttachUserPolicy, AttachRolePolicy, CreatePolicyVersion,
AddMemberToRole, AddGroupMember, SudoersModification]
- condition: |
privilege_level(post_change) > privilege_level(pre_change)
AND change_actor != provisioning_service_account
enrichments:
- itsm_ticket: servicenow, jira (linked_change_id)
- behavioral_baseline: admin_activity_hours, known_ips
- post_change_activity: cloudtrail_5m_window
mitre: T1078.004, T1098 (Account Manipulation)What privilege change occurred — role assignment, policy attach, group membership, or sudo add?
Cloud / AD auditWho made the privilege change — an admin account or the affected user themselves?
IAM audit logWas this change part of a ticket in Jira, ServiceNow, or a change management system?
ITSM integrationDoes the affected user's role historically include admin access?
IAM baselineDid any high-risk API call occur within 5 minutes of the privilege grant?
CloudTrail / GCP auditHas this admin account made privilege changes outside business hours before?
Behavioral baselineIs the granting account a shared or service account rather than a named human?
Identity graphCreate a time-stamped snapshot of the pre- and post-change IAM policy for forensic comparison
AutonomousAlert the granting admin's manager with change details and a revocation link
AutonomousIf no linked ticket found: pause privilege activation pending analyst approval
Approve-gatedRevoke the elevated privilege if analyst confirms unauthorized change
Approve-gatedIf post-privilege API activity is sensitive (PassRole, AssumeRole, CreateAccessKey): escalate to IR
RecommendLegacy SOC comparison
CloudTrail logs the AttachUserPolicy event. The SIEM rule, if it exists at all, fires a low-severity alert that gets buried under EDR noise. The analyst who reviews it has no ITSM context and no view of what the account did after receiving the policy. They close it as "admin activity, likely authorized." Three days later, the attacker uses the account to exfiltrate 200 GB from S3.
MITRE ATT&CK mapping
Privilege escalation FAQ
Does this cover both cloud IAM and on-premises Active Directory privilege changes?
Yes. ManySignal monitors AWS IAM, Azure RBAC, GCP IAM, Okta group changes, Active Directory group membership changes, and Linux sudoers modifications. All are normalized into the same privilege-change event model for unified detection and correlation.
What's the difference between this and a CSPM misconfiguration alert?
CSPM scans for standing misconfigurations on a schedule. ManySignal detects the moment of change — who made it, from which IP, linked to which ticket. This provides the investigative context that turns a misconfiguration finding into an attributable security event.
How does ManySignal handle break-glass admin accounts?
Break-glass accounts are tagged in the identity graph. Any activation of a break-glass account generates a P1 alert regardless of context. The playbook includes a mandatory post-use audit and time-limited session capture.
Can the detection distinguish between automated provisioning and manual escalation?
Yes. ManySignal integrates with Terraform, Ansible, and IaC pipeline tokens. Privilege changes made by known IaC service accounts with linked pipeline run IDs are suppressed. Manual escalations — especially via console or CLI from a human session — are flagged.
Catch unauthorized privilege grants before they're exploited
IAM change monitoring across AWS, Azure, GCP, and Active Directory — with ticket correlation built in.