Which First Action Confirms a Coordinated Login Attack in SecOps?

PSOE By islever Editorial Last updated

Performing threat hunting across environments. Developing and implementing mechanisms to detect risks and identify threats.

Short answer

B Run a UDM Search for recent IOCs across the suspicious login attempts to confirm whether they represent a coordinated attack.

Question

You are a security analyst at an organization that uses Google Security Operations (SecOps). You notice suspicious login attempts on several user accounts. You need to determine whether these attempts are part of a coordinated attack as quickly as possible. What action should you take first?
  1. Enable default curated detections to automatically block suspicious IP addresses.
  2. Use UDM Search to query historical logs for recent IOCs associated with the suspicious login attempts. Correct Answer
  3. Remove user accounts that have repeated invalid login attempts.
  4. Look for correlations across impacted users in the Risk Analytics dashboard.

Key Takeaways

The question tests the correct first investigative pivot for multi-account login anomalies, and the trap is jumping to automated blocking or destructive containment before correlation evidence exists.

Google SecOps analysts facing suspicious logins across several accounts must pivot quickly to confirm whether the activity is a coordinated attack. This page establishes that a UDM Search correlating recent IOCs across the impacted users is the correct first action before any blocking or account-removal step.

Common mistake: Option D is the most tempting wrong choice, since the Risk Analytics dashboard sounds like it 'correlates users,' but it surfaces pre-configured risk scores and rule-based signals rather than giving you an immediate, query-driven pivot across raw events for the IOCs you just observed.

Expert Analysis

Why the Answer Is Correct

Option B, a UDM Search, is the fastest way to test coordination because it lets you immediately query the ingested event data for the IPs, user agents, ASNs, or other IOCs seen in the suspicious logins and group results across all impacted accounts in one pass. Objective 3.1 treats threat hunting across environments as an analyst-driven search activity, and UDM Search is the primary interface for that in Google SecOps. Confirming or ruling out coordination with actual event evidence must precede any irreversible containment action. The top community votes converged on this as the direct first pivot, which matches how SecOps investigations are normally launched.

Why the Other Options Are Wrong

Option A enables curated detections that auto-block IPs, which is a preventive control that neither confirms nor explains whether the attempts are coordinated, and it may block legitimate traffic before you understand the pattern. Option C removes user accounts, a destructive containment step that destroys investigative context and disables users before you have evidence, so it can never be the first action in an assessment question. Option D relies on the Risk Analytics dashboard, which reports risk scores produced by pre-existing rules; if no risk rules cover these users, the dashboard shows nothing, and even when populated it does not let you pivot on specific IOCs the way a query does. Option D is a valid later check, but not the fastest first move.

Community Comment Notes

As acloudboy put it, "The first action you should take is to analyze the suspicious login attempts using the UDM Search feature" — the highest-liked comment. caitlynth added the reasoning that the same IP, User-Agent, or ASN hitting "several user accounts" within a short window signals password spraying or credential stuffing, and that "UDM Search is the most direct first-pivot" for comparing IOCs across users. Hamza_hmz123 also recorded "Corrected Answer: B," and no commenter defended the dashboard-first approach.

Official Reference

https://cloud.google.com/security-operations

This link opens the official vendor documentation in a new tab.

Exam Strategy

On 'what should you do first' questions, always choose the non-destructive evidence-gathering action over blocking, disabling, or deleting anything. Confirm the tool named in the option can actually answer the specific question asked — correlation via query beats a dashboard only populated by pre-configured rules.

Frequently Asked Questions

Why is using the Risk Analytics dashboard not the right first step here?

Risk Analytics only shows scores from pre-configured risk rules and does not let you pivot on specific IOCs. Use UDM Search first for direct correlation, then check risk signals as a follow-up.

Why can't I block suspicious IPs or remove the accounts first?

Both are containment actions taken before you have evidence the logins are coordinated. Block or disable only after the search confirms the pattern and scope of the attack.

More PSOE FAQ →

Discussion 3 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 3

  1. acloudboy 👍 3 Answered B
    The first action you should take is to analyze the suspicious login attempts using the UDM Search feature within Google Security Operations (SecOps)
  2. caitlynth 👍 1 Answered B
    "several user accounts" and "coordinated attack" If the same IP address, User-Agent, or ASN attempts to log in to multiple accounts within a short period of time, it is very likely due to password spraying, credential stuffing, or coordinated brute-force attacks. UDM Search is the most direct first-pivot: comparing common IOCs among multiple users and confirming whether it's part of the same attack.
  3. Hamza_hmz123 👍 1 Answered B
    Corrected Answer : B

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Ingesting On-Prem NAS Logs into Google SecOps Without IP Aliasing

S-grade

Which Log Source Completes principal.user.userid Matching?

S-grade

Reducing Secops Alert Noise with High-Value Asset Context

S-grade

Handling Vendor Parser Field Changes in Google SecOps

S-grade

← Back to PSOE Study Guide