Skip to main content

More Info:

Detect rapid failed logins followed immediately by a success. This pattern strongly indicates a successful password spraying or credential stuffing attack against an identity account.

Risk Level

High

Address

Compliance, Security

Compliance Standards

  • APRA CPS 234 (Australia)
  • AWS Well Architected Framework
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS AWS
  • CIS Critical Security Controls v8
  • CMMC 2.0
  • CSA Cloud Controls Matrix v4
  • Cloudanix Best Practice
  • DPDPA
  • Digital Operational Resilience Act (EU)
  • Essential 8
  • HIPAA
  • ISO 27001
  • ISO/IEC 27017
  • ISO/IEC 27018
  • ISO/IEC 27701
  • KSA PDPL
  • MAS Technology Risk Management (Singapore)
  • MITRE ATT&CK (Cloud)
  • NIS2 Directive
  • NIST CSF
  • NIST SP 800-171
  • NYDFS 23 NYCRR 500
  • SWIFT Customer Security Controls Framework
  • Sarbanes-Oxley IT General Controls
  • UK NCSC Cyber Assessment Framework

Triage and Remediation

Remediation

Using Console

Below is a practical way to meet the “password spray detection” requirement using only OCI native services via the Console, with security best-practice in mind:Because OCI Monitoring alarms are metric-based, and password-spray is a security pattern, not a numeric metric, the normal and supported approach is:
  1. Use Cloud Guard to detect password spray.
  2. Attach Notifications so your SOC/SRE gets alerted (email, Slack, PagerDuty, etc.).

1. Make sure Cloud Guard is enabled

  1. Sign in to the OCI Console.
  2. Open the navigation menu → Identity & SecurityCloud Guard.
  3. If Cloud Guard is not enabled:
    • Click Enable Cloud Guard.
    • Choose a compartment where you want Cloud Guard configuration stored.
    • Choose Reporting Region (usually your home region).
    • Click Enable.

2. Confirm / enable the Password Spray detector

  1. Still in Cloud Guard, go to ConfigurationDetector Recipes.
  2. Find the Managed Detector Recipe for Identity (for example, something like:
    OCI Activity Detector Recipe or similar, depending on tenancy naming).
  3. Click the recipe name.
  4. Search in the Detectors list for Password Spray (e.g., “Password Spray Attack” or similar wording).
  5. Ensure:
    • The detector is Enabled.
    • The Risk Level is set appropriately (e.g., High).
  6. If needed, click Edit:
    • Turn Enabled on.
    • Save changes.
If you are using a cloned/custom recipe attached to your Cloud Guard target, edit the cloned recipe, not the managed one.

3. Attach the detector recipe to a Cloud Guard target

  1. In Cloud Guard, go to Targets.
  2. Either:
    • Edit an existing target, or
    • Click Create Target to cover the tenancy or a specific compartment.
  3. In the target:
    • Under Detector Recipes, make sure the Identity/Activity Detector Recipe (the one with Password Spray) is attached.
  4. Click Save changes.
At this point, Cloud Guard will generate problems whenever a password spray pattern is detected.

4. Configure Notifications for Password Spray problems

4.1 Create a Notifications topic

  1. Open the navigation menu → Developer ServicesNotifications (or Application IntegrationNotifications depending on your console layout).
  2. Click Create Topic.
  3. Name it something like: password-spray-alerts.
  4. Click Create.

4.2 Add subscriptions

  1. Click on your new topic.
  2. Under Subscriptions, click Create Subscription.
  3. Choose protocol, for example:
    • Email → provide the email address(es).
    • Or HTTPS, Slack via Webhook, PagerDuty, etc.
  4. Click Create.
  5. For emails, open your inbox and confirm the subscription.

5. Connect Cloud Guard to Notifications (for password spray)

You can notify for all High-severity problems (which should include Password Spray) or explicitly for that problem type if using filtering downstream.
  1. In Cloud Guard, go to ConfigurationResponder Recipes (if you want auto-responses) or ConfigurationEvents depending on your console version.
  2. Simpler route: use Events Service to watch Cloud Guard problems and forward to Notifications.

5.1 Create an Event rule for Cloud Guard Password Spray

  1. Go to navigation menu → Observability & ManagementEvents ServiceRules.
  2. Click Create Rule.
  3. Name: cloudguard-password-spray-alert.
  4. Rule Conditions:
    • Set Event Type: com.oraclecloud.cloudguard.createproblem or similar Cloud Guard problem event.
    • Add a filter in the Additional Condition (JSON) to match Password Spray problem type, e.g. (pattern may vary by tenancy):
    If your tenancy uses a specific problem type key (e.g., data.additionalDetails.problemType), filter on that instead.
  5. Actions:
    • Select Notifications.
    • Choose the topic password-spray-alerts.
  6. Click Create Rule.
Now, when Cloud Guard creates a Password Spray problem, Events Service will push a message to Notifications, which will send email/Slack/etc.

6. (Optional) Expose as a Monitoring Alarm

If your policy or tooling explicitly requires an OCI Monitoring Alarm object, you can:
  1. Use a small external process (Function, script, SIEM) that:
    • Reads Cloud Guard problems (via Events or Cloud Guard API).
    • Writes a custom metric to OCI Monitoring when a Password Spray problem appears (e.g., metric security.password_spray_detected = 1).
  2. Then, in the Console:
    • Go to Observability & ManagementMonitoringAlarmsCreate alarm.
    • Choose the custom metric namespace.
    • Set a query such as:
    • Point the alarm to the same Notifications topic.
This last piece requires some glue code, since OCI Monitoring itself cannot directly parse Cloud Guard events.
Summary:
Using only Console, the supported way is: Cloud Guard Password Spray detector → Events Rule → Notifications. If you must have a “Monitoring Alarm” object, add a custom-metric writer in between and create an alarm on that metric.
Below is one way to remediate this using OCI CLI by wiring a Cloud Guard “Password Spray” problem to an OCI Monitoring alarm and a Notification topic.

1. Prerequisites

  • OCI CLI installed and configured (oci setup config done).
  • You know:
    • Your compartment OCID (e.g. ocid1.compartment.oc1..xxxxx)
    • Your region (e.g. us-ashburn-1)
    • Your tenancy OCID if needed (ocid1.tenancy.oc1..xxxxx)
Set env vars for convenience (optional):

2. Enable Cloud Guard and the Password Spray Detector

  1. Enable Cloud Guard at tenancy level (if not already enabled):
  1. List available detector recipes and find the one including password-spray logic (often a managed detector recipe for IAM):
Look for something like OCI Managed Detector Recipe that has IAM-related rules. Get its OCID, e.g.:
  1. List detector rules in that recipe and verify the “Password Spray” rule is enabled:
Find a rule whose name/description indicates “Password Spray” (e.g. Password Spray in IAM). Note its rule ID:
  1. Ensure the rule is enabled:
Cloud Guard will now create a Problem any time a password-spray pattern is detected. These problems are exposed as metrics in Monitoring under the oci_cloud_guard namespace.

3. Create a Notification Topic and Subscription

  1. Create a Notifications topic:
Capture the topic OCID from output:
  1. Create an email subscription to that topic:
Confirm the subscription via the email that’s sent.

4. Create the Monitoring Alarm for Password Spray Problems

Cloud Guard exposes problem metrics roughly in the namespace oci_cloud_guard. A common pattern is:
  • Namespace: oci_cloud_guard
  • Metric: problems_count
  • Dimension filters: e.g. problemType = "PASSWORD_SPRAY" (name may vary; adjust to actual value returned by Cloud Guard in your tenancy).
  1. Test metric availability (optional):
  1. Create the alarm:
Adjust the metric query if your exact dimension keys/values differ. The example below fires if at least one password-spray problem appears in the last 5 minutes.
Key fields you may need to adjust:
  • problemType = "PASSWORD_SPRAY"
    • Use the actual value from your Cloud Guard problems. If unsure, inspect a Password Spray problem:
      Then update the filter in query-text to match e.g. {problemType = "PASSWORD_SPRAY_IN_IAM"} if that’s what you see.

5. Validate

  1. Confirm alarm exists and is enabled:
  1. Trigger (or wait for) a test password-spray event (or temporarily lower threshold) and confirm:
    • A Cloud Guard Problem is created.
    • The alarm state changes to FIRING.
    • An email is received from the Notifications topic.

If you share the exact problemType and metric layout from your tenancy, I can refine the --query-text to match precisely.
Below is a practical way to remediate this in OCI using Monitoring + Alarms via Python:Goal:
Have an OCI Monitoring Alarm that fires when a “password spray” pattern is detected, using Python/OCI SDK.
Because OCI doesn’t provide a built‑in “password spray” metric, you’ll typically:
  1. Detect the pattern from logs (e.g., Audit/IDCS logs).
  2. Push a custom metric to OCI Monitoring when detected.
  3. Create an Alarm on that custom metric.

1. Prerequisites

  • Python 3.x
  • oci Python SDK:
  • An OCI config file (~/.oci/config) with a profile that has access to:
    • Monitoring (metrics + alarms)
    • Logs or Audit (to read login failures if you’re doing detection in Python)
  • A target compartment OCID where you will:
    • Publish custom metric
    • Create the alarm

2. Decide Password Spray Detection Logic

One simple heuristic (you can improve as needed):
  • Same IP address
  • Multiple user login failures (e.g., ≥5) within a short time window (e.g., 5 minutes)
  • Against different usernames
You can implement this logic outside OCI (e.g., in a Python script or OCI Function) that:
  1. Periodically pulls login failure events from:
    • OCI Audit or
    • Logging or
    • IDCS logs (if federated)
  2. Groups them by source IP and time window.
  3. If the threshold is exceeded, push a metric value 1 (or count) to OCI Monitoring.
Below I assume you have some way of identifying a password-spray condition in Python (e.g., a function is_password_spray_detected()).

3. Push a Custom Metric to OCI Monitoring (Python)

Namespace: security_password_spray
Metric name: password_spray_detected
Dimension example: {"source": "audit-checker"}
You’d normally run this script regularly (cron, OCI Function, container, etc.).

4. Create the Alarm on the Custom Metric (Python)

Alarm logic: if password_spray_detected sum over any 5‑minute window is ≥ 1, trigger alarm.
Adjust the query syntax based on the Monitoring query language version you use. A common pattern:
If using metric[interval].sum(), ensure it matches your SDK/region Monitoring capabilities.

5. Wire Detection + Metric Publishing

Your overall flow:
  1. Script or Function runs every N minutes.
  2. It reads login failure logs (Audit/IDCS/Logging).
  3. Applies password-spray logic.
  4. If detected, sends metric value 1, otherwise 0.
  5. Alarm continuously evaluates the metric and sends notifications.

6. Quick Checklist

  • Audit/IDCS log source accessible from Python
  • Password-spray detection logic implemented
  • Custom metric posting working (visible in OCI Console → Monitoring → Metrics)
  • Alarm created and enabled (visible in OCI Console → Monitoring → Alarms)
  • Notification topic configured with email / PagerDuty / etc.
If you share how you currently store/receive login failures (Audit vs IDCS vs custom logs), I can give a minimal working detection example in Python tailored to that source.