IR-1: Compromised Tenant Account

A compromised tenant account occurs when an unauthorized actor gains access to a customer organization’s Arbitex account — either a specific user account or the full organization. This playbook covers detection through recovery.

For real-time session and authentication monitoring, see Security Operations. For credential rotation procedures, see Credential Management.

---

1. Detection

This incident is typically detected through one or more of the following signals:

Signal	Audit action / source	Notes
Unusual login geography	auth.login_success with anomalous GeoIP	Enriched by GeoIP middleware
Impossible travel	Two auth.login_success events from distant regions within minutes	Time-delta check
Brute force followed by success	Multiple auth.login_failed then auth.login_success	Same user or same IP
Customer report	Out-of-band — email, phone, support ticket	Highest trust signal
Anomalous API key creation	credential.created audit event in unexpected timeframe	Possible persistence mechanism
Policy or DLP rule change	policy.updated or dlp.rule_updated event	Lateral access or sabotage attempt

Query audit events to confirm signals:

# List recent auth events for a specific org
curl -s "https://api.arbitex.ai/api/v1/admin/audit-logs/?org_id=<org_uuid>&action=auth.login_success&limit=100" \
  -H "Authorization: Bearer $STAFF_TOKEN" | jq '.'

# Filter for impossible travel (auth.login_success from multiple IPs for one user)
curl -s "https://api.arbitex.ai/api/v1/admin/audit-logs/?user_id=<user_uuid>&action=auth.login_success&limit=50" \
  -H "Authorization: Bearer $STAFF_TOKEN" | jq '.events[] | {timestamp, source_ip, metadata}'

---

2. Severity classification

Condition	Severity
Suspicious login detected, no confirmed unauthorized access	MEDIUM
Confirmed unauthorized login — no data access observed	HIGH
Unauthorized login with API key creation or policy changes	HIGH
Data access confirmed (API calls, DLP events, exports)	CRITICAL
Data exfiltration confirmed (large content volume, export operations)	CRITICAL

Escalate to CRITICAL immediately if:

• Audit logs show bulk export operations (audit.export) by the unauthorized actor
• DLP scan results show sensitive content in response payloads during the breach window
• New API keys, OAuth clients, or users were created during the breach window

---

3. Immediate actions (first 15 minutes)

Complete these steps in order. Do not skip steps to save time — the sequence matters.

Step	Action	Command / UI
1	Declare incident	POST /api/staff/incident/declare
2	Identify all org users	List org users to build target list
3	Revoke all org sessions	DELETE /api/v1/admin/users/{user_id}/sessions for each user
4	Isolate tenant (if CRITICAL)	POST /api/staff/emergency/tenant/isolate
5	Freeze audit log	POST /api/staff/emergency/audit/freeze
6	Begin investigation	Query audit trail (section 4)

Step 1 — Declare incident:

curl -s -X POST "https://api.arbitex.ai/api/staff/incident/declare" \
  -H "Authorization: Bearer $STAFF_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Compromised tenant account — org <org_uuid>",
    "severity": "HIGH",
    "playbook": "IR-1",
    "org_id": "<org_uuid>"
  }' | jq '{incident_id: .id, ic_expires: .ic_window_expires}'

Save the returned incident_id — use it in all subsequent calls.

Step 2 — List org users:

curl -s "https://api.arbitex.ai/api/v1/admin/users?org_id=<org_uuid>&limit=200" \
  -H "Authorization: Bearer $STAFF_TOKEN" | jq '[.users[] | {id, email, last_login}]'

Step 3 — Revoke all sessions for each org user:

# Loop over all user IDs in the org
for USER_ID in $(curl -s "https://api.arbitex.ai/api/v1/admin/users?org_id=<org_uuid>" \
  -H "Authorization: Bearer $STAFF_TOKEN" | jq -r '.users[].id'); do
  echo "Revoking sessions for $USER_ID"
  curl -s -X DELETE "https://api.arbitex.ai/api/v1/admin/users/${USER_ID}/sessions" \
    -H "Authorization: Bearer $STAFF_TOKEN"
done

Step 4 — Tenant isolation (CRITICAL only):

curl -s -X POST "https://api.arbitex.ai/api/staff/emergency/tenant/isolate" \
  -H "Authorization: Bearer $STAFF_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "org_id": "<org_uuid>",
    "incident_id": "<incident_id>",
    "reason": "Compromised account — IR-1 protocol, investigation in progress"
  }'

Tenant isolation disables all API access for the org. The customer will receive 403 responses until restored. Notify the customer contact immediately after isolation (see section 7).

---

4. Investigation

Collect evidence and determine scope before containment. Target: understand what the unauthorized actor accessed, created, or modified.

Check active sessions before revocation is complete:

curl -s "https://api.arbitex.ai/api/v1/admin/sessions?org_id=<org_uuid>" \
  -H "Authorization: Bearer $STAFF_TOKEN" | jq '.sessions[] | {session_id, user_id, source_ip, created_at, last_seen}'

Check for API key creation during breach window:

curl -s "https://api.arbitex.ai/api/v1/admin/audit-logs/?org_id=<org_uuid>&action=credential.created&created_after=<breach_start_iso>&created_before=<breach_end_iso>" \
  -H "Authorization: Bearer $STAFF_TOKEN" | jq '.events'

Check for policy or DLP modifications:

# Policy changes
curl -s "https://api.arbitex.ai/api/v1/admin/audit-logs/?org_id=<org_uuid>&action=policy.updated&created_after=<breach_start_iso>" \
  -H "Authorization: Bearer $STAFF_TOKEN"

# DLP rule changes
curl -s "https://api.arbitex.ai/api/v1/admin/audit-logs/?org_id=<org_uuid>&action=dlp.rule_updated&created_after=<breach_start_iso>" \
  -H "Authorization: Bearer $STAFF_TOKEN"

Check for data access patterns:

# Review audit events for large response payloads or exports
curl -s "https://api.arbitex.ai/api/v1/admin/audit-logs/?org_id=<org_uuid>&action=audit.export&created_after=<breach_start_iso>" \
  -H "Authorization: Bearer $STAFF_TOKEN"

Verify HMAC audit chain integrity for the breach window:

curl -s -X POST "https://api.arbitex.ai/api/v1/admin/audit/verify" \
  -H "Authorization: Bearer $STAFF_TOKEN" \
  | jq '{valid, total_entries, errors}'

A valid: true result confirms the audit chain was not tampered with during the breach window.

---

5. Containment

After investigation establishes scope, execute containment in order of risk:

Action	When required	Command
Revoke all org credentials	Any unauthorized API access confirmed	POST /api/staff/emergency/credentials/revoke-all
Revoke specific compromised key	Specific key identified	DELETE /api/v1/admin/credentials/{id}
Disable outpost sync (if org uses Outpost)	Lateral movement to Outpost suspected	POST /api/staff/emergency/outpost/disconnect
Lock DLP configuration	DLP rules were modified	POST /api/staff/emergency/killswitch

Bulk credential revocation:

curl -s -X POST "https://api.arbitex.ai/api/staff/emergency/credentials/revoke-all" \
  -H "Authorization: Bearer $STAFF_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "org_id": "<org_uuid>",
    "incident_id": "<incident_id>",
    "reason": "IR-1: Compromised account — revoking all org credentials pending recovery"
  }' | jq '{revoked_count: .revoked, credential_ids: .ids}'

Revoke a specific credential by ID:

curl -s -X DELETE "https://api.arbitex.ai/api/v1/admin/credentials/<credential_id>" \
  -H "Authorization: Bearer $STAFF_TOKEN"

Disable outpost sync (if applicable):

curl -s -X POST "https://api.arbitex.ai/api/staff/emergency/outpost/disconnect" \
  -H "Authorization: Bearer $STAFF_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"org_id": "<org_uuid>", "incident_id": "<incident_id>"}'

---

6. Recovery

Only begin recovery after containment is complete and the unauthorized actor is confirmed evicted.

Step	Action	Verification
1	Verify identity with org admin	Out-of-band contact (phone, existing trusted channel)
2	Revert any malicious changes	Restore policy, DLP, user changes from audit log
3	Restore tenant access	POST /api/staff/emergency/tenant/restore
4	Issue new credentials	POST /api/v1/admin/credentials/{id}/rotate
5	Verify clean audit trail	POST /api/v1/admin/audit/verify (verifies caller’s org)
6	Confirm platform health	GET /readyz, GET /health/deep

Restore tenant access:

curl -s -X POST "https://api.arbitex.ai/api/staff/emergency/tenant/restore" \
  -H "Authorization: Bearer $STAFF_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "org_id": "<org_uuid>",
    "incident_id": "<incident_id>",
    "reason": "Identity verified with org admin, breach contained"
  }'

Rotate a specific credential to issue fresh secret:

curl -s -X POST "https://api.arbitex.ai/api/v1/admin/credentials/<credential_id>/rotate" \
  -H "Authorization: Bearer $STAFF_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"grace_period_seconds": 0}'

Setting grace_period_seconds: 0 prevents the previous secret from remaining valid during any grace window — appropriate after a confirmed compromise.

Verify platform health after recovery:

curl -s "https://api.arbitex.ai/readyz" | jq '.'
curl -s "https://api.arbitex.ai/health/deep" | jq '{status, db, redis, providers}'

---

7. Communication

Initial notification to customer (within 30 minutes of confirmation)

Send via email to the org’s primary security contact and Slack/Teams (if integration exists):

Subject: [URGENT] Security alert — unauthorized access to your Arbitex account

We have detected unauthorized access to your Arbitex organization account.

We have immediately:
- Terminated all active sessions for your organization
- Suspended API access pending investigation
- Frozen your audit log to preserve evidence

Action required from you:
1. Reply to this email to confirm your identity with our security team
2. Do not attempt to create new API keys until you hear from us
3. Review any recent changes to your configuration

Your account reference: [ORG_ID]
Incident reference: [INCIDENT_ID]
Time of detection: [ISO_TIMESTAMP]

Contact: [email protected] | [DIRECT_PHONE]

Escalation to Arbitex legal (CRITICAL / exfiltration confirmed)

If data exfiltration is confirmed, notify Arbitex legal within 1 hour of confirmation. Provide:

• Incident ID
• Org ID and customer name
• Estimated data volume accessed
• Categories of data (conversation content, PII, credentials)
• Jurisdiction (for breach notification timing requirements)

Audit export for customer

Provide the customer with a full audit export of events during and around the breach window:

curl -s -X POST "https://api.arbitex.ai/api/v1/admin/audit/export" \
  -H "Authorization: Bearer $STAFF_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "org_id": "<org_uuid>",
    "start_date": "<breach_start_date>",
    "end_date": "<recovery_complete_date>",
    "format": "json",
    "include_metadata": true
  }' -o "incident-<incident_id>-audit-export.json"

---

8. Post-incident

Evidence preservation checklist:

Item	Status
Audit export (full breach window) saved to secure storage	[ ]
HMAC chain verification result recorded	[ ]
Session list at time of detection captured	[ ]
All IP addresses and GeoIP data logged	[ ]
All modified resources inventoried (policies, DLP rules, users, credentials)	[ ]
Incident timeline document created	[ ]

Close the incident when recovery is verified:

curl -s -X POST "https://api.arbitex.ai/api/staff/incident/<incident_id>/close" \
  -H "Authorization: Bearer $STAFF_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "resolution": "Unauthorized actor evicted, credentials rotated, tenant restored, customer notified",
    "root_cause": "<describe: phishing / credential stuffing / insider / unknown>",
    "data_exfiltrated": false
  }'

Lessons learned template:

• What was the initial detection signal and how long before response?
• Were there any detection signals missed in the hours before discovery?
• Did the tenant isolation cause unintended service disruption for legitimate users?
• Were communication templates adequate and sent within SLA?
• Were any platform-level controls (rate limiting, impossible travel alerting) that could have prevented or reduced the impact absent?

Related playbooks:

• If API keys were created by the attacker: follow IR-2: Compromised API Key
• If DLP rules were modified: follow IR-3: DLP Bypass Detected
• If outpost was involved: follow IR-4: Outpost Compromise