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
HighAddress
Compliance, SecurityCompliance 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
Remediation
Using Console
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:
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.
- Use Cloud Guard to detect password spray.
- Attach Notifications so your SOC/SRE gets alerted (email, Slack, PagerDuty, etc.).
1. Make sure Cloud Guard is enabled
- Sign in to the OCI Console.
- Open the navigation menu → Identity & Security → Cloud Guard.
- 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
- Still in Cloud Guard, go to Configuration → Detector Recipes.
- Find the Managed Detector Recipe for Identity (for example, something like:
OCI Activity Detector Recipeor similar, depending on tenancy naming). - Click the recipe name.
- Search in the Detectors list for Password Spray (e.g., “Password Spray Attack” or similar wording).
- Ensure:
- The detector is Enabled.
- The Risk Level is set appropriately (e.g., High).
- 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
- In Cloud Guard, go to Targets.
- Either:
- Edit an existing target, or
- Click Create Target to cover the tenancy or a specific compartment.
- In the target:
- Under Detector Recipes, make sure the Identity/Activity Detector Recipe (the one with Password Spray) is attached.
- Click Save changes.
4. Configure Notifications for Password Spray problems
4.1 Create a Notifications topic
- Open the navigation menu → Developer Services → Notifications (or Application Integration → Notifications depending on your console layout).
- Click Create Topic.
- Name it something like:
password-spray-alerts. - Click Create.
4.2 Add subscriptions
- Click on your new topic.
- Under Subscriptions, click Create Subscription.
- Choose protocol, for example:
- Email → provide the email address(es).
- Or HTTPS, Slack via Webhook, PagerDuty, etc.
- Click Create.
- 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.- In Cloud Guard, go to Configuration → Responder Recipes (if you want auto-responses) or Configuration → Events depending on your console version.
- 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
- Go to navigation menu → Observability & Management → Events Service → Rules.
- Click Create Rule.
-
Name:
cloudguard-password-spray-alert. -
Rule Conditions:
- Set Event Type:
com.oraclecloud.cloudguard.createproblemor 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. - Set Event Type:
-
Actions:
- Select Notifications.
- Choose the topic
password-spray-alerts.
- Click Create Rule.
6. (Optional) Expose as a Monitoring Alarm
If your policy or tooling explicitly requires an OCI Monitoring Alarm object, you can:- 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).
- Then, in the Console:
- Go to Observability & Management → Monitoring → Alarms → Create alarm.
- Choose the custom metric namespace.
- Set a query such as:
- Point the alarm to the same Notifications topic.
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.
Using CLI
Using CLI
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.
Look for something like Find a rule whose name/description indicates “Password Spray” (e.g. 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
Capture the topic OCID from output:Confirm the subscription via the email that’s sent.
Key fields you may need to adjust:
If you share the exact
1. Prerequisites
- OCI CLI installed and configured (
oci setup configdone). - 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)
- Your compartment OCID (e.g.
2. Enable Cloud Guard and the Password Spray Detector
- Enable Cloud Guard at tenancy level (if not already enabled):
- List available detector recipes and find the one including password-spray logic (often a managed detector recipe for IAM):
OCI Managed Detector Recipe that has IAM-related rules. Get its OCID, e.g.:- List detector rules in that recipe and verify the “Password Spray” rule is enabled:
Password Spray in IAM). Note its rule ID:- Ensure the rule is enabled:
oci_cloud_guard namespace.3. Create a Notification Topic and Subscription
- Create a Notifications topic:
- Create an email subscription to that topic:
4. Create the Monitoring Alarm for Password Spray Problems
Cloud Guard exposes problem metrics roughly in the namespaceoci_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).
- Test metric availability (optional):
- Create the alarm:
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-textto match e.g.{problemType = "PASSWORD_SPRAY_IN_IAM"}if that’s what you see.
-
Use the actual value from your Cloud Guard problems. If unsure, inspect a Password Spray problem:
5. Validate
- Confirm alarm exists and is enabled:
- 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.Using Python
Using Python
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:
Metric name:
Dimension example:You’d normally run this script regularly (cron, OCI Function, container, etc.).
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:
- Detect the pattern from logs (e.g., Audit/IDCS logs).
- Push a custom metric to OCI Monitoring when detected.
- Create an Alarm on that custom metric.
1. Prerequisites
- Python 3.x
ociPython 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
- Periodically pulls login failure events from:
- OCI Audit or
- Logging or
- IDCS logs (if federated)
- Groups them by source IP and time window.
- If the threshold is exceeded, push a metric value
1(or count) to OCI Monitoring.
is_password_spray_detected()).3. Push a Custom Metric to OCI Monitoring (Python)
Namespace:security_password_sprayMetric name:
password_spray_detectedDimension example:
{"source": "audit-checker"}4. Create the Alarm on the Custom Metric (Python)
Alarm logic: ifpassword_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 usingmetric[interval].sum(), ensure it matches your SDK/region Monitoring capabilities.
5. Wire Detection + Metric Publishing
Your overall flow:- Script or Function runs every N minutes.
- It reads login failure logs (Audit/IDCS/Logging).
- Applies password-spray logic.
- If detected, sends metric value
1, otherwise0. - 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.
Using Terraform
Using Terraform

