Use Case: Cloud
Cloud persistence detection
After gaining initial access, the attacker created an IAM user named 'terraform-worker' with an access key at 2:17 AM. The account was still active 11 days later when IR found it. ManySignal would have caught it in 90 seconds.
The backdoor that survives credential rotation
After establishing initial access via a compromised AWS IAM credential, the first goal of a sophisticated attacker is persistence: maintaining access even if the original credential is revoked. In cloud environments, the preferred method is creating a new, low-profile IAM user or service principal with independent credentials. These backdoor accounts often masquerade as service accounts used by automation tools — names like 'terraform-worker', 'github-deploy', or 'monitoring-agent' that don't raise suspicion in an environment that has many legitimate automation accounts.
rule: cloud_persistence_creation
type: cloud_audit + provisioning_correlation
sources:
- aws_cloudtrail
- azure_activity_log
- gcp_admin_activity
trigger:
- event: [CreateUser, CreateAccessKey, CreateServicePrincipal,
AddKeyCredential, CreateServiceAccountKey]
- condition: |
actor NOT IN [iac_provisioning_roles, hr_provisioning_service]
AND event_time NOT IN [maintenance_windows]
AND actor.ip NOT IN [corporate_ip_ranges]
enrichments:
- provisioning_correlation: terraform_run, jira_ticket, hr_event
- actor_history: recent_iam_changes, compromise_indicators
- new_account_activity: first_api_calls_post_creation
mitre: T1136.003 (Create Account: Cloud Account)MITRE ATT&CK mapping
Cloud persistence FAQ
What cloud persistence mechanisms does ManySignal detect?
AWS: backdoor IAM users, access key creation for existing accounts, Lambda backdoor functions, EC2 instance profile abuse, and S3 lifecycle policy changes. Azure: guest account creation, service principal secret addition, Automation account runbooks, and Logic App modifications. GCP: service account key creation, Cloud Function deployment, and OAuth app registration. All normalized into the same persistence event model.
How does ManySignal distinguish legitimate account creation from a backdoor?
Legitimate account creation typically correlates with an HR system event, an IT ticket, or a Terraform run. Backdoor accounts are created by compromised IAM principals outside business hours, from unusual IPs, without a linked provisioning workflow, often with minimal attributes and immediate access key generation.
Can ManySignal detect persistence via cloud-native services (Lambda, Functions)?
Yes. Serverless backdoors — Lambda functions or Azure Functions that beacon home, exfiltrate data, or create additional access keys — are detected via two signals: the deployment event (who created the function, from where) and the runtime behavior (outbound connections from the function to suspicious endpoints).
Is this the same as CSPM posture checking?
No. CSPM scans for standing misconfigurations on a schedule. ManySignal detects the persistence event at the moment of creation with full actor attribution. A backdoor IAM user created at 2 AM by a compromised role fires an alert within 90 seconds of the CreateUser API call.
Detect cloud backdoor accounts within 90 seconds of creation
Real-time IAM change monitoring with provisioning workflow correlation across AWS, Azure, and GCP.