T1578.002 Splunk · SPL

Detect Create Cloud Instance in Splunk

An adversary may create a new instance or virtual machine (VM) within the compute service of a cloud account to evade defenses. Creating a new instance may allow an adversary to bypass firewall rules and permissions that exist on instances currently residing within an account. An adversary may create a snapshot of one or more volumes in an account, create a new instance, mount the snapshots, and then apply a less restrictive security policy to collect data from local system or for remote data staging. LAPSUS$ has been observed creating new virtual machines within target cloud environments after leveraging credential access to cloud assets. Scattered Spider has created Amazon EC2 instances within victim environments to establish persistence and stage exfiltrated data. This technique enables adversaries to operate in an isolated compute environment without affecting existing running instances, evading endpoint-based detection tools that only monitor known workloads.

MITRE ATT&CK

Tactic
Defense Evasion
Technique
T1578 Modify Cloud Compute Infrastructure
Sub-technique
T1578.002 Create Cloud Instance
Canonical reference
https://attack.mitre.org/techniques/T1578/002/

SPL Detection Query

Splunk (SPL)
spl
index=* (sourcetype="aws:cloudtrail" OR sourcetype="azure:monitor:activity")
| eval CloudProvider=case(
    sourcetype="aws:cloudtrail", "AWS",
    sourcetype="azure:monitor:activity", "Azure",
    true(), "Unknown"
  )
| eval IsInstanceCreate=case(
    CloudProvider="AWS" AND eventName="RunInstances", 1,
    CloudProvider="Azure" AND match(lower(operationName), "microsoft\.compute/virtualmachines/write"), 1,
    true(), 0
  )
| where IsInstanceCreate=1
| eval Actor=case(
    CloudProvider="AWS", coalesce('userIdentity.arn', 'userIdentity.userName', "unknown"),
    CloudProvider="Azure", coalesce(caller, "unknown"),
    true(), "unknown"
  )
| eval SourceIP=case(
    CloudProvider="AWS", sourceIPAddress,
    CloudProvider="Azure", callerIpAddress,
    true(), "unknown"
  )
| eval SuccessStatus=case(
    CloudProvider="AWS", if(isnull(errorCode) OR errorCode="", "Succeeded", "Failed"),
    CloudProvider="Azure", if(match(lower(status), "succeeded"), "Succeeded", "Other"),
    true(), "Unknown"
  )
| where SuccessStatus="Succeeded"
| eval Scope=case(
    CloudProvider="AWS", awsRegion,
    CloudProvider="Azure", resourceGroup,
    true(), "unknown"
  )
| eval AccountScope=case(
    CloudProvider="AWS", recipientAccountId,
    CloudProvider="Azure", subscriptionId,
    true(), "unknown"
  )
| table _time, CloudProvider, Actor, SourceIP, SuccessStatus, Scope, AccountScope
| sort - _time
high severity medium confidence

Detects cloud instance creation events across AWS CloudTrail and Azure Monitor Activity logs in Splunk. Uses conditional evaluation to normalize event fields from both cloud providers into a unified schema. Focuses on successful instance creation (RunInstances for AWS, virtualMachines/write for Azure) to identify potential defense evasion through new compute resource provisioning. Requires Splunk Add-on for AWS (sourcetype aws:cloudtrail) and Splunk Add-on for Microsoft Cloud Services (sourcetype azure:monitor:activity).

Data Sources

Cloud Service: Cloud Service ModificationAWS CloudTrailAzure Monitor Activity Logs

Required Sourcetypes

aws:cloudtrailazure:monitor:activity

False Positives & Tuning

  • Authorized DevOps pipelines and CI/CD systems creating ephemeral compute instances for build and test workloads
  • Auto-scaling group events triggered by legitimate load increases — RunInstances is called by AWS Auto Scaling service roles
  • Infrastructure-as-Code deployments by authorized engineers using Terraform, CloudFormation, or Bicep applied through service accounts
  • Disaster recovery testing and cloud migration activities provisioning parallel infrastructure in secondary regions
  • Cloud security scanning tools that deploy agent or assessment instances into target environments
Download portable Sigma rule (.yml)

Other platforms for T1578.002


Testing Methodology

Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Create AWS EC2 Instance via CLI

    Expected signal: AWS CloudTrail: RunInstances event with eventSource=ec2.amazonaws.com, eventName=RunInstances, userIdentity block showing caller ARN and accountId, requestParameters.instancesSet containing imageId and instanceType t2.micro, responseElements.instancesSet.items[0].instanceId with the assigned instance ID. Event appears in CloudTrail within 5-15 minutes and in Microsoft Sentinel AWSCloudTrail table within 15-30 minutes depending on connector polling interval.

  2. Test 2Create Azure Virtual Machine via CLI

    Expected signal: Azure Activity Log: Microsoft.Compute/virtualMachines/write operation with ActivityStatus=Succeeded, Caller showing the authenticated UPN or service principal object ID, CallerIpAddress of the machine running the Azure CLI, ResourceGroup=df00tech-atomic-test-rg. Also generates Microsoft.Resources/resourceGroups/write event for the preceding resource group creation. Events appear in Azure Activity Log within 5 minutes and in Microsoft Sentinel AzureActivity table within 10-15 minutes.

  3. Test 3Create GCP Compute Engine Instance via gcloud CLI

    Expected signal: GCP Cloud Audit Log: compute.instances.insert activity log entry with principalEmail showing the authenticated caller, requestMetadata.callerIp, resource.labels.instance_id and resource.labels.zone populated. Visible in GCP Cloud Logging under GCE Audit Logs (Admin Activity). If exported to Microsoft Sentinel via GCP Pub/Sub connector: GCPAuditLogs table with MethodName=v1.compute.instances.insert and Severity=NOTICE (success).

  4. Test 4Snapshot-then-Create-Instance Data Staging Pattern (Mandiant M-Trends)

    Expected signal: AWS CloudTrail sequence: (1) CreateVolume event with responseElements.volumeId, (2) CreateSnapshot event with requestParameters.volumeId and responseElements.snapshotId from the same userIdentity.arn, (3) RunInstances event with requestParameters.blockDeviceMapping containing the snapshotId in the Ebs block. All three events share the same userIdentity.arn and sessionContext. Entire sequence visible in CloudTrail within 15 minutes.

Unlock Pro Content

Get the full detection package for T1578.002 including response playbook, investigation guide, and atomic red team tests.

Response PlaybookInvestigation GuideHunting QueriesAtomic Red Team TestsTuning Guidance

Related Detections