Orca Investigate

Orca Investigate Skill

Answers the question: "What happened, who did it, and how far did they get?"

Given an actor (IAM identity), source IP, target resource, or suspicious event, traces activity through Orca CDR (CloudTrail/audit logs), builds a session timeline, maps actions to MITRE ATT&CK techniques, clusters related sessions, and assesses the blast radius.

Usage

/orca-investigate arn:aws:iam::123456789012:role/bastion-admin-role
/orca-investigate 10.0.1.50
/orca-investigate account 123456789012

Or natural language:

• "investigate what this role did in the last 24 hours"
• "trace activity from IP 10.0.1.50"
• "what happened in this account today?"
• "investigate suspicious AssumeRole events"
• "who accessed the prod database?"
• "incident investigation for orca-3636513"

Processing Logic

Step 1: Determine Investigation Scope

Parse user input to determine the investigation axis:

Determine time range:

• Default: "last_24_hours" for active incidents
• "last 3 days" / "last week" → "last_3_days" / "last_7_days"
• User-specified → map to nearest CDR enum

Step 2: Gather Data (run ALL in parallel)

Query 1: Events by the actor/from the source/on the target

search_cdr_events:
  <primary filter>: [<value>]
  time_range: "<selected range>"
  limit: 100

Query 2: Event summary grouped by action

get_cdr_events_grouped_by_event_name:
  <primary filter>: [<value>]
  time_range: "<selected range>"
  page_size: 100

Query 3: If actor-based, also search as target

search_cdr_events:
  targets: ["<actor ARN>"]
  time_range: "<selected range>"
  limit: 50

(To find events done TO this identity — policy changes, permission grants, etc.)

Query 4: If alert-initiated, fetch the alert

get_alert:
  alert_id: "<alert-id>"

Query 5: Related alerts on the asset

get_asset_related_alerts_summary:
  asset_id: <UUID>

Query 6: Related attack paths

get_asset_related_attack_paths_summary:
  asset_id: <UUID>

Step 3: Build Session Timeline

From CDR events, construct a chronological timeline:

1. Sort all events by timestamp
2. Cluster into sessions based on:
   • Same actor + same source IP + events within 30-minute gaps = one session
   • Actor change or long gap = new session
3. For each session:
   • Start time, end time, duration
   • Source IP(s) and user-agent(s)
   • Actions performed (in order)
   • Resources touched
   • Success/failure status of each action

Step 4: MITRE ATT&CK Mapping

Map observed actions to MITRE ATT&CK for Cloud:

CDR Action                          MITRE Technique                    Tactic
──────────────────────────────────────────────────────────────────────────────────
ConsoleLogin                        T1078 — Valid Accounts             Initial Access
AssumeRole (cross-account)          T1550.001 — Web Session Cookie     Lateral Movement
AssumeRole (same account)           T1078.004 — Cloud Accounts         Privilege Escalation
CreateUser / CreateAccessKey        T1136.003 — Cloud Account          Persistence
AttachUserPolicy / PutRolePolicy    T1098.003 — Additional Cloud Roles Persistence
PutBucketPolicy (public)            T1537 — Transfer to Cloud Account  Exfiltration
GetObject (bulk S3)                 T1530 — Data from Cloud Storage    Collection
DescribeInstances / ListBuckets     T1580 — Cloud Infrastructure       Discovery
RunInstances                        T1578.002 — Create Cloud Instance  Resource Hijacking
StopLogging / DeleteTrail           T1562.008 — Disable Cloud Logs     Defense Evasion
ModifyInstanceAttribute             T1578 — Modify Cloud Compute       Execution
AuthorizeSecurityGroupIngress       T1562.007 — Disable Cloud Firewall Defense Evasion
DeleteSnapshot / DeleteBucket       T1485 — Data Destruction           Impact
GetSecretValue / GetParameter       T1552.004 — Cloud Secrets          Credential Access
Invoke / InvokeFunction             T1648 — Serverless Execution       Execution
PutObject (to external account)     T1537 — Transfer to Cloud Account  Exfiltration
CreateSnapshot (shared externally)  T1537 — Transfer to Cloud Account  Exfiltration

For each mapped technique, assess:

• Confidence: HIGH (action directly matches) / MEDIUM (action could be benign) / LOW (speculative)
• Context: Was it expected for this identity's role?

Step 5: Assess Blast Radius

Determine the scope of impact:

1. Resources touched — how many distinct resources were accessed/modified?
2. Services involved — how many AWS/Azure/GCP services?
3. Accounts reached — any cross-account activity?
4. Data access — any data stores accessed (S3, RDS, Secrets Manager)?
5. Persistence indicators — any new users, keys, roles, or policies created?
6. Defense evasion — any logging/monitoring changes?
7. Lateral movement — any role assumptions or cross-account jumps?

Classify blast radius:

CONTAINED     — activity limited to 1-2 resources in 1 service
MODERATE      — multiple resources or services, same account
BROAD         — multiple accounts or significant data access
SEVERE        — persistence established + data accessed + evasion attempted

Step 6: Generate Verdict

IF defense_evasion AND persistence AND data_access THEN
  "ACTIVE COMPROMISE — containment needed NOW"
ELSE IF persistence OR cross_account_lateral_movement THEN
  "PROBABLE COMPROMISE — investigate and contain"
ELSE IF unusual_actions AND (off_hours OR new_source_ip) THEN
  "SUSPICIOUS — requires investigation"
ELSE IF actions_match_role AND normal_hours AND known_ips THEN
  "LIKELY BENIGN — routine activity"
ELSE
  "INCONCLUSIVE — need more data"

Proactive Remediation Behavior

CRITICAL: Never leave the user with just data. After EVERY output layer, suggest the next action and offer to generate containment/remediation code.

After the dashboard and after every drill-down section:

1. Suggest what to do next — based on the verdict, recommend containment or remediation
2. Offer remediation format selection — always ask: "I can generate containment scripts. What format do you prefer?"
3. Supported formats: Terraform, CloudFormation, Ansible, CLI commands (aws/az/gcloud), step-by-step instructions, Pulumi, ARM/Bicep
4. Urgency-based suggestions:
   • ACTIVE COMPROMISE → "I can generate containment scripts NOW — revoke access, isolate resources"
   • PROBABLE COMPROMISE → "I can generate investigation runbooks and containment scripts"
   • SUSPICIOUS → "I can generate detection rules and monitoring configs"
   • LIKELY BENIGN → "I can generate an allowlist rule or close the alert"

When the user selects a format:

• Generate the containment/remediation code immediately (IAM policy revocation, security group isolation, credential rotation, detection rules)
• Write it to a file: contain-<actor-or-resource>.<ext> (e.g., .tf, .yml, .sh)
• Include verification commands and rollback instructions
• Suggest the next investigation step after containment

Format mapping:

Output Format

Layer 1: Dashboard

═══════════════════════════════════════════════════════════════════
INVESTIGATION — <scope description>
<actor/IP/resource> | <time range>
═══════════════════════════════════════════════════════════════════

VERDICT: <assessment> | CONFIDENCE: <X%>

┌─────────────────────────────────────────────────────────────────┐
│  EVENTS          <N> total, <M> unique actions                  │
│  SESSIONS        <N> distinct sessions                          │
│  TIME SPAN       <first event> → <last event> (<duration>)     │
│  SERVICES        <N> AWS/Azure/GCP services touched             │
│  RESOURCES       <N> distinct resources accessed                │
│  SOURCE IPs      <N> unique IPs (<classification>)              │
│  USER AGENTS     <N> unique (<classification>)                  │
│  BLAST RADIUS    <CONTAINED / MODERATE / BROAD / SEVERE>        │
│  MITRE ATT&CK   <N> techniques mapped across <M> tactics       │
│  ALERTS          <N> related alerts on involved assets          │
│  ATTACK PATHS    <N> kill chains involving this actor           │
└─────────────────────────────────────────────────────────────────┘

EXECUTIVE SUMMARY:
  <2-3 sentences: what happened, what's the risk, what to do next>

MITRE ATT&CK COVERAGE:
  ■ Initial Access    ■ Execution    □ Persistence    □ Priv Esc
  □ Defense Evasion   ■ Discovery    □ Lateral Move   ■ Collection
  □ Exfiltration      □ Impact
  (■ = observed, □ = not observed)

RECOMMENDED ACTION:
  <Based on verdict — e.g., "Containment needed: revoke access
  for <actor> and rotate credentials. I can generate the scripts.">

  What format? terraform | cloudformation | ansible | cli |
  instructions | pulumi | arm/bicep

═══════════════════════════════════════════════════════════════════
Or drill down: timeline | sessions | mitre | blast radius |
actions | resources | alerts | iocs | contain | full
═══════════════════════════════════════════════════════════════════

Layer 2: Drill-Down Sections

"timeline" — Chronological Event Timeline

───────────────────────────────────────────────────────────────────
TIMELINE — <scope>
───────────────────────────────────────────────────────────────────

<date/time>  <action>
             Actor: <identity>
             Target: <resource>
             Source: <IP> (<classification>)
             Agent: <user-agent> (<classification>)
             Status: <success/failure>
             MITRE: <technique if mapped>

<date/time>  <action>
             ...

[... continues chronologically ...]

KEY MOMENTS:
  <time> — <significant event description>
  <time> — <significant event description>

───────────────────────────────────────────────────────────────────

"sessions" — Clustered Sessions

───────────────────────────────────────────────────────────────────
SESSIONS — <scope>
───────────────────────────────────────────────────────────────────

SESSION 1: <start> → <end> (<duration>)
  Actor: <identity>
  Source: <IP> (<classification>)
  Agent: <user-agent>
  Actions: <N> total
    <action> × <count>
    <action> × <count>
    ...
  Resources: <list>
  Assessment: <normal / suspicious / malicious>

SESSION 2: <start> → <end>
  ...

SESSION COMPARISON:
  <note any unusual sessions — off-hours, new IPs, different behavior>

───────────────────────────────────────────────────────────────────

"mitre" — MITRE ATT&CK Mapping

───────────────────────────────────────────────────────────────────
MITRE ATT&CK MAPPING — <scope>
───────────────────────────────────────────────────────────────────

TACTIC              TECHNIQUE                  ACTION              CONFIDENCE
──────────────────────────────────────────────────────────────────────────────
Initial Access      T1078 Valid Accounts       ConsoleLogin        HIGH
Discovery           T1580 Cloud Infra Disc     DescribeInstances   MEDIUM
Collection          T1530 Cloud Storage Data   GetObject           HIGH
...

KILL CHAIN ASSESSMENT:
  Tactics covered: <N> of 10
  Chain completeness: <PARTIAL / NEAR-COMPLETE / COMPLETE>
  Missing for full chain: <tactics not observed>
  
  Assessment: <interpretation of the ATT&CK coverage>

───────────────────────────────────────────────────────────────────

"blast radius" — Impact Assessment

───────────────────────────────────────────────────────────────────
BLAST RADIUS — <scope>
───────────────────────────────────────────────────────────────────

SCOPE: <CONTAINED / MODERATE / BROAD / SEVERE>

RESOURCES ACCESSED:
  <service>: <N> resources
    <resource ARN> — <action performed>
    ...

DATA STORES TOUCHED:
  <S3 bucket / RDS / DynamoDB / etc.> — <action> (<N> events)
  Crown jewel: YES/NO

ACCOUNTS INVOLVED:
  <account-1> — <N> events
  <account-2> — <N> events (CROSS-ACCOUNT!)

PERSISTENCE INDICATORS:
  [!] New user created: <user ARN>
  [!] New access key: <key ID>
  [!] Policy attached: <policy> to <identity>
  (or: None detected)

DEFENSE EVASION:
  [!] Trail stopped/deleted
  [!] Security group modified
  (or: None detected)

CONTAIN NOW:
  I can generate scripts to revoke access, isolate resources,
  and rotate credentials. Choose format: terraform |
  cloudformation | ansible | cli | instructions | pulumi |
  arm/bicep

───────────────────────────────────────────────────────────────────

"actions" — All Actions Summary

───────────────────────────────────────────────────────────────────
ACTIONS — <scope>
───────────────────────────────────────────────────────────────────

  Action                          Count   Service          Risk
  ──────────────────────────────────────────────────────────────
  <action>                        <N>     <service>        <assessment>
  <action>                        <N>     <service>        <assessment>
  ...

BY SERVICE:
  <service>: <N> events (<M> unique actions)
  ...

BY RISK:
  HIGH RISK: <list of dangerous actions>
  NORMAL:    <list of routine actions>

───────────────────────────────────────────────────────────────────

"resources" — Resources Touched

───────────────────────────────────────────────────────────────────
RESOURCES — <scope>
───────────────────────────────────────────────────────────────────

  <resource ARN/name>
    Type: <resource type>
    Actions: <list of actions performed on it>
    Crown jewel: YES/NO
    Alerts: <N> open alerts

  <resource ARN/name>
    ...

───────────────────────────────────────────────────────────────────

"iocs" — Indicators of Compromise

───────────────────────────────────────────────────────────────────
INDICATORS OF COMPROMISE — <scope>
───────────────────────────────────────────────────────────────────

IP ADDRESSES:
  <IP> — <classification> | <N> events | <services>

USER AGENTS:
  <agent> — <classification> | <N> events

IDENTITIES:
  <ARN> — <role in the investigation>

RESOURCES CREATED (potential persistence):
  <ARN> — created at <time>

ACCESS KEYS:
  <key ID> — created for <user> at <time>

SHARE THESE WITH YOUR SOC:
  [Copy-paste block of IOCs for threat intel tools]

AUTOMATE DETECTION:
  I can generate detection rules or monitoring configs for
  these IOCs. Choose format: terraform (CloudWatch/GuardDuty) |
  ansible | cli | instructions

───────────────────────────────────────────────────────────────────

"contain" — Containment Recommendations

───────────────────────────────────────────────────────────────────
CONTAINMENT — Recommended Actions
───────────────────────────────────────────────────────────────────

IMMEDIATE (within 1 hour):
  [ ] <action 1> — <why and how>
  [ ] <action 2> — <why and how>

SHORT-TERM (within 24 hours):
  [ ] <action> — <context>
  [ ] <action> — <context>

INVESTIGATION NEXT STEPS:
  [ ] <what to check next>
  [ ] <what to check next>

EVIDENCE PRESERVATION:
  [ ] Snapshot affected instances before changes
  [ ] Export CloudTrail logs for the period
  [ ] Document current state of modified resources

GENERATE CONTAINMENT CODE:
  I'll create implementation scripts for the actions above.
  Choose format: terraform | cloudformation | ansible | cli |
  step-by-step runbook | pulumi | arm/bicep

  After containment, I can help with:
  • /orca-identity-review <actor> — review and right-size permissions
  • /orca-asset-profile <resource> — full profile of affected assets
  • Detection rule generation — prevent recurrence

───────────────────────────────────────────────────────────────────

"full" — Everything Expanded

Show all sections in order.

Edge Cases

No CDR Events Found

⚠ No CDR events found for <input> in <time range>.

Possible reasons:
  • Identity/resource hasn't been active in this period
  • CloudTrail/audit log ingestion not configured for this account
  • CDR retention has expired for older events
  • The actor ARN may be different (check aliases/assumed roles)

Try:
  • Extend time range: /orca-investigate <input> last 30 days
  • Search by account: /orca-investigate account <account-id>
  • Check CDR configuration in Orca Console

Too Many Events (> 1000)

Note: High event volume (<N> events). Showing top 100 by relevance.

For high-volume actors (automation/services), consider:
  • Filtering by specific action: /orca-investigate <actor> action CreateUser
  • Filtering by time: /orca-investigate <actor> last 1 hour
  • Using Orca CDR UI for full event exploration

Alert-Initiated Investigation

When starting from an alert:

1. Fetch the alert to get actor/target context
2. Use the alert's actor ARN as the primary CDR filter
3. Include the alert's timeline in the investigation timeline
4. Cross-reference with related alerts on the same asset

Cross-Account Activity

Flag prominently:

⚠ CROSS-ACCOUNT ACTIVITY DETECTED

This actor accessed resources in multiple accounts:
  <account-1> — <N> events
  <account-2> — <N> events

Cross-account activity significantly increases blast radius.
Review each account separately for full impact.

MCP Tools Used

Primary Tools

Secondary Tools

CDR Parameter Reference

All array parameters MUST be arrays even for single values:

Implementation Notes

1. Parallelize CDR queries — event search and grouped summary are independent.
2. Session clustering is key — raw events are overwhelming; sessions tell a story.
3. MITRE ATT&CK mapping adds analyst value — don't just list events, classify them.
4. Blast radius drives urgency — "3 resources in 1 service" vs "50 resources across 5 accounts" changes the response.
5. IOCs section should be copy-paste ready for SOC tools.
6. Link to other skills — suggest /orca-alert-triage for related alerts, /orca-identity-review for the actor's permissions, /orca-asset-profile for touched assets.
7. Cross-account activity is always HIGH priority — flag it prominently.
8. CDR retention is limited — note if events may be missing due to time range limits.