Oracle Cloud Infrastructure (OCI) Account Compromised: Complete Recovery Guide

Oracle Cloud Infrastructure (OCI) may not be as widely discussed in cloud security circles as AWS or Azure, but it is absolutely targeted by attackers — and for a specific reason that makes it particularly attractive: the OCI Always Free tier offers powerful compute resources (ARM-based Ampere A1 instances, 4 OCPUs, 24GB RAM) that remain free indefinitely. Attackers who compromise an OCI account can spin up free-tier compute for cryptomining, DDoS infrastructure, or as a staging ground for further attacks — all at zero cost, and with the compromised account holder facing potential account suspension and reputational damage.

Beyond the free tier, paid OCI accounts are targeted for the same reasons as other clouds: cryptocurrency mining using GPU shapes (BM.GPU4.8 at over $20/hour), data exfiltration from Object Storage, and abuse of Autonomous Database provisioning. This guide covers every step of OCI incident response from first discovery through full recovery and hardening.

How OCI Accounts Get Compromised

Understanding OCI's specific attack vectors helps you prioritize your investigation:

OCI CLI configuration files: The OCI CLI stores API keys in plain text at ~/.oci/config on developer machines. Malware, a compromised developer laptop, or a leaked configuration in a Docker image can expose these keys. Unlike cloud role-based credentials, these API keys have no expiration by default.
API key exposure in code repositories: The OCI API key fingerprint and private key PEM file are commonly committed to GitHub repositories by accident, especially in CI/CD configurations and Terraform state files.
Instance Principal token theft via SSRF: OCI Compute instances can be assigned an Instance Principal credential that allows them to call OCI APIs. SSRF attacks against the instance metadata endpoint can steal these tokens.
Resource Principal abuse: Similar to AWS Lambda execution roles, OCI Functions use Resource Principals. A vulnerable function can have its principal credentials stolen.
Federated Identity compromise: OCI supports federation with SAML identity providers. If your IdP is compromised, attackers can authenticate to OCI through it.
Console credential theft: Phishing attacks targeting Oracle single sign-on pages steal console username and password combinations.

Phase 1: First 15 Minutes — Immediate Containment

Step 1: Identify the Compromise Scope

Navigate to the OCI Console (cloud.oracle.com) and immediately check:

Cost & Usage — Is there unusual spending?
Compute → Instances — Are there instances you did not create?
Identity & Security → Users — Are there unfamiliar users?
Audit — Are there recent actions you did not perform?

Step 2: Disable Compromised API Keys Immediately

API key compromise is the most common OCI attack vector. Navigate to Identity & Security → Users → [affected user] → API Keys. For each API key, look at the fingerprint and the last use time. Disable any key you suspect is compromised (OCI allows disabling without deleting, which is useful for forensics).

# Using OCI CLI to list all API keys for a user
oci iam user api-key list --user-id ocid1.user.oc1..YOUR_USER_OCID

# Disable a specific API key
oci iam user api-key delete   --user-id ocid1.user.oc1..YOUR_USER_OCID   --fingerprint "aa:bb:cc:dd:ee:ff:00:11:22:33:44:55:66:77:88:99"

# List all users in a tenancy with their status
oci iam user list --all   --query 'data[*].{name:"name", id:"id", status:"lifecycle-state", mfa:"is-mfa-activated"}'   --output table

Step 3: Block Compromised IAM Users

Navigate to Identity & Security → Users. For any user that is compromised, click on the user and select Block User. This prevents all console and API access without deleting the user (preserving audit records). Also invalidate all active sessions.

# Block a user using OCI CLI
oci iam user update   --user-id ocid1.user.oc1..YOUR_USER_OCID   --blocked true

# List all active user sessions
oci iam user-group-membership list --all   --user-id ocid1.user.oc1..YOUR_USER_OCID

Step 4: Terminate Unauthorized Compute Instances

Check all compartments for unauthorized instances. Attackers frequently create new compartments to hide resources from the default compartment view. Navigate to Compute → Instances and change the compartment filter to check all compartments.

# List all compute instances across all compartments
oci compute instance list   --compartment-id ocid1.tenancy.oc1..YOUR_TENANCY_OCID   --all   --query 'data[*].{name:"display-name", state:"lifecycle-state", shape:"shape", region:"region", created:"time-created"}'   --output table

# Stop an unauthorized instance (preserves it for forensics)
oci compute instance action   --instance-id ocid1.instance.oc1..YOUR_INSTANCE_OCID   --action SOFTSTOP

# Terminate an unauthorized instance
oci compute instance terminate   --instance-id ocid1.instance.oc1..YOUR_INSTANCE_OCID   --preserve-boot-volume true

Step 5: Lock Down IAM Policies

OCI uses compartment-based IAM policies with a deny-by-default model. If an attacker has modified IAM policies to grant themselves access, add a temporary restrictive policy at the tenancy level to override them. Navigate to Identity & Security → Policies and add an emergency deny statement:

In OCI policy syntax, there is no explicit deny — you achieve lockdown by removing policy statements that grant access. The OCI IAM model only allows allow statements, so removing a policy removes the access entirely. Delete or modify any policies that grant unexpected permissions.

Phase 2: First Hour — Forensic Investigation

Step 6: Analyze OCI Audit Logs

OCI Audit logs capture every API call made to OCI services. They are retained for 90 days and cannot be disabled by users (only Oracle can disable them, which means even if an attacker tries to hide tracks, audit records remain). Navigate to Observability & Management → Audit.

# Query Audit logs for a specific time range using OCI CLI
oci audit event list   --compartment-id ocid1.tenancy.oc1..YOUR_TENANCY_OCID   --start-time 2026-03-13T00:00:00Z   --end-time 2026-03-14T23:59:59Z   --all   --query 'data[*].{time:"event-time", user:"data.identity.principal-name", ip:"data.request.headers.x-real-ip[0]", action:"data.request.action", resource:"data.resource.name"}'   --output table 2>/dev/null | head -100

# Search for specific event types (IAM changes)
oci audit event list   --compartment-id ocid1.tenancy.oc1..YOUR_TENANCY_OCID   --start-time 2026-03-13T00:00:00Z   --all   --query 'data[?contains(data.request.action, `iam`)]'   --output json

In the OCI Console Audit service, use the filter bar to narrow results. Key things to search for:

Event type: CreateUser — attacker creating a backdoor user
Event type: CreateApiKey — attacker adding API keys to existing accounts
Event type: CreateCompartment — attacker hiding resources in new compartments
Event type: LaunchInstance — unauthorized compute instances
Event type: CreatePolicy / UpdatePolicy — privilege escalation
Event type: DeleteAuditPolicy — attacker attempting to disable logging

Step 7: Check All Compartments for Unauthorized Resources

Attackers frequently create new compartments to avoid detection. List all compartments in your tenancy:

# List all compartments in the tenancy
oci iam compartment list   --compartment-id ocid1.tenancy.oc1..YOUR_TENANCY_OCID   --all   --include-root   --query 'data[*].{name:"name", id:"id", created:"time-created", state:"lifecycle-state"}'   --output table

# Check for instances in each compartment
for comp_id in $(oci iam compartment list   --compartment-id ocid1.tenancy.oc1..YOUR_TENANCY_OCID   --all --include-root --query 'data[*].id' --raw-output 2>/dev/null); do
  echo "--- Compartment: $comp_id ---"
  oci compute instance list     --compartment-id $comp_id     --query 'data[*].{name:"display-name",state:"lifecycle-state",shape:"shape"}'     --output table 2>/dev/null
done

Step 8: Check Object Storage Buckets

Navigate to Storage → Object Storage → Buckets and check for buckets with public access that you did not configure, and for unexpected buckets that may be staging areas for exfiltrated data.

# List all Object Storage buckets in a compartment
oci os bucket list   --compartment-id YOUR_COMPARTMENT_OCID   --all   --fields publicAccessType   --query 'data[*].{name:"name", access:"public-access-type", created:"time-created"}'   --output table

# Check for buckets with public access
oci os bucket list   --compartment-id YOUR_COMPARTMENT_OCID   --all   --fields publicAccessType   --query 'data[?public-access-type!=`NoPublicAccess`]'   --output table

Step 9: Check Autonomous Database and Other PaaS Resources

OCI Autonomous Database is frequently targeted — it can store sensitive data and is expensive. Check for any Autonomous Database instances you did not create:

# List all Autonomous Databases
oci db autonomous-database list   --compartment-id YOUR_COMPARTMENT_OCID   --all   --query 'data[*].{name:"display-name", state:"lifecycle-state", cpu:"cpu-core-count", storage:"data-storage-size-in-tbs", created:"time-created"}'   --output table

# List all Kubernetes (OKE) clusters
oci ce cluster list   --compartment-id YOUR_COMPARTMENT_OCID   --all   --query 'data[*].{name:"name", state:"lifecycle-state", created:"metadata.time-created"}'   --output table

Phase 3: Identifying the Compromise Vector

Step 10: Trace the Compromised API Key

OCI Audit logs include the API key fingerprint used for each request. Cross-reference the fingerprint in the audit logs with the API keys listed on each user. This pinpoints exactly which key was compromised and when it was first used maliciously.

Look in the Audit log event JSON for the identity.credentials field, which contains the fingerprint of the API key used. Alternatively, the identity.principal-name field shows the user or instance principal that made the request.

Step 11: Check for Exposed OCI Configuration Files

Search your code repositories, CI/CD systems, and Docker image layers for the OCI config file format. The ~/.oci/config file has a very recognizable structure:

# What a leaked OCI config looks like (this is the format to search for)
# [DEFAULT]
# user=ocid1.user.oc1..aaaaaaaa...
# fingerprint=aa:bb:cc:dd:...
# tenancy=ocid1.tenancy.oc1..aaaaaaaa...
# region=us-ashburn-1
# key_file=~/.oci/oci_api_key.pem

# Search your git history for OCI OCIDs
# (run this in your code repository directory)
git log --all --oneline | head -5  # First check if you have git history
git log --all -p -- "*.pem" "*.config" "config" | grep -A5 "ocid1.user"

Phase 4: Full Remediation

Step 12: Rotate All API Keys

Even after identifying the specific compromised key, rotate all API keys across all users. In OCI, you can have up to 3 API keys per user. The process for each user:

Navigate to Identity & Security → Users → [user] → API Keys
Click "Add API Key" and generate a new key pair
Download the new private key PEM file securely
Update all applications and CLI configurations to use the new key
Delete the old keys after confirming the new key works

Step 13: Regenerate Auth Tokens

OCI Auth Tokens are used for Docker registry authentication with Oracle Container Registry and for HTTPS connections to certain OCI APIs. These are separate from API keys. Navigate to Identity & Security → Users → [user] → Auth Tokens and delete all existing tokens, then generate new ones as needed.

Step 14: Reset All User Passwords and Console Access

For all IAM users with console access, force a password reset. Navigate to each user and click "Create/Reset Password". Require that MFA be re-enrolled by disabling current MFA configurations and requiring users to set it up again on their next login.

Step 15: Clean Up Unauthorized Resources and Compartments

Systematically delete unauthorized resources in this order:

Terminate compute instances (keep boot volumes briefly for forensics)
Delete load balancers and gateways (to stop ongoing traffic)
Delete object storage buckets (after documenting their contents)
Terminate databases
Delete the compartment (OCI requires a compartment to be empty before deletion)
Remove unauthorized IAM policies
Remove unauthorized users

Phase 5: Billing Dispute with Oracle

Step 16: Document and Report Unauthorized Charges

Navigate to OCI Console → Billing & Cost Management → Cost Analysis. Set the date range to the attack period and identify all unauthorized charges by service, compartment, and resource type.

Contact Oracle Cloud support through:

OCI Console → Help → Support Center → Create Service Request
Select "Billing" as the service category
Select "Dispute a charge" or "Unauthorized account activity" as the issue type
Priority: Critical

Oracle's billing fraud policy is less publicly documented than AWS or Azure's, but Oracle does review unauthorized charge claims. Your case is stronger when you can demonstrate:

The specific resources were created without your authorization (supported by Audit log evidence)
The resources were running during a period when your credentials were known to be compromised
You responded quickly, terminated the unauthorized resources, and rotated all credentials
You have implemented additional security controls to prevent recurrence

Escalate to your Oracle account representative if you have one — enterprise and government customers especially may have escalation paths that move faster than standard support. Be persistent. Initial responses may be denials, but a well-documented incident report with Audit log exports typically results in at least partial credits.

Phase 6: OCI Security Hardening

IAM and Access Hardening

Enable MFA enforcement for all users through the Password Policy in Identity settings. OCI supports TOTP (Time-Based One-Time Password) and FIDO2 hardware keys
Implement compartment-based least privilege — every developer should work in their own compartment with an IAM policy scoped to only that compartment
Use Instance Principals and Resource Principals instead of API keys for services running on OCI infrastructure — this eliminates the most common attack vector entirely
Set API key expiration policies — OCI does not enforce API key rotation by default, but you can implement this via service request or by auditing regularly
Enable Identity Domain features including account lockout policies (lock after 5 failed attempts) and session timeout policies

Monitoring and Detection

Enable Cloud Guard — OCI's free built-in security monitoring service that detects misconfigurations and threats like public buckets, open security list rules, and suspicious activity patterns
Enable Vulnerability Scanning on all compute instances — this scans for known OS and application vulnerabilities
Set up OCI Notifications for Audit events: user creation, API key creation, policy changes, and instance launches. Route these to email or PagerDuty for immediate alerting
Enable Flow Logs on all VCNs (Virtual Cloud Networks) for network traffic monitoring
Use OCI Logging to centralize logs from Audit, VCN Flow Logs, Load Balancer logs, and application logs into a single Log Group with retention of 6+ months

Network Security

Use Security Lists and Network Security Groups with strict ingress rules — never allow 0.0.0.0/0 on port 22 (SSH) or 3389 (RDP). Use OCI Bastion Service for secure instance access
Enable OCI Bastion for SSH/RDP access to private instances — this provides time-limited, audited sessions without public IP exposure
Use Service Gateway and NAT Gateway appropriately to control outbound traffic and prevent lateral movement via the internet
Enable Web Application Firewall (WAF) on all public-facing applications to block common exploitation attempts

Data Protection

Set Object Storage Bucket visibility to Private by default — enable the tenancy-level policy to prevent public access unless explicitly authorized
Enable Object Storage replication to a separate region for critical data
Use OCI Vault (Key Management) for encryption key management and enable customer-managed encryption keys (CMK) for sensitive Object Storage buckets and Autonomous Databases
Enable Autonomous Database access control lists (ACLs) to restrict connectivity to known IP ranges

The Always Free Tier Risk

A specific warning about the OCI Always Free tier: these resources are attractive to attackers precisely because they generate no charges, meaning standard billing-based anomaly detection will not catch the abuse. If someone compromises an OCI account and uses only Always Free resources, you may not notice for weeks or months — until your account is suspended by Oracle for abuse.

Mitigate this by enabling Cloud Guard (which detects policy violations regardless of billing), setting up Audit log alerting for all resource creation events, and periodically auditing all compartments for unexpected resources even if your bill looks normal.

Oracle Cloud is a serious enterprise cloud platform with strong security capabilities, but its security controls are less well-known than AWS or Azure's. This means many OCI users are operating with weaker security postures than they realize. Cloud Guard, OCI Bastion, Vault, and proper IAM compartmentalization provide strong baseline security — but only if you enable and configure them.

If you need help with OCI security architecture, an incident response assessment, or implementing the controls described in this guide, ZeonEdge's cloud security team works across all major cloud platforms including Oracle Cloud Infrastructure.