Credential Stuffing Investigation
This scenario covers a large-scale automated login attack using credentials leaked from third-party breaches. The goal is to determine whether any accounts were successfully taken over and to contain the impact.
Scenario
A SIEM or WAF alert fires on a spike of authentication failures across dozens of source IPs targeting the customer portal or employee VPN. The requests share a common pattern — one login attempt per IP, rotating through a username list — which is characteristic of credential stuffing rather than brute force. Shortly after the spike, one login succeeds from an IP that has never accessed the system before.
Create the case
Open Alerts and locate the alert. Click Preview, review the Similar cases tab for prior login anomalies from overlapping IP ranges, then select the Credential Stuffing template from the Import alert as dropdown and click Yes, Import.
The case is created with the following tasks:
Task |
Group |
Action |
|---|---|---|
Identify compromised accounts |
Identification |
From authentication logs, list all accounts that had a successful login during the attack window, especially from IPs not seen in that account’s login history. Cross-reference with the list of IPs flagged in the alert. |
Verify login origin |
Identification |
For each successful login from an unknown IP, check the country of origin, ASN, and whether the IP belongs to a known VPN provider, proxy, or botnet. Flag logins from countries where the organisation has no operations. |
Revoke active sessions |
Containment |
Force logout all active sessions for each account confirmed or suspected to be compromised. Use the identity platform’s session revocation API or the BlockUser responder if immediate account suspension is required. |
Reset credentials |
Containment |
Initiate a forced password reset for all affected accounts. Notify users via a secondary channel — not the potentially compromised email address. |
Block attack infrastructure |
Containment |
Feed the source IP list to a firewall or WAF responder to block further requests. If the IPs resolve to a known botnet or proxy service, apply a broader block by ASN or IP range where policy allows. |
Add observables and run analyzers
Open the Observables tab and click Add Observable. Add:
Source IPs (type
ip) — a representative sample of the attacking IPs.Targeted usernames (type
other) — accounts that received login attempts.User-agent string (type
other) — the HTTP user-agent used by the attacker tool.Successful login IP (type
ip) — the IP from which the account takeover occurred.
Select the source IPs and the successful login IP, click Run Analyzers, and run IP reputation analyzers. Check results for:
Membership in known botnet or credential stuffing infrastructure lists.
ASN ownership — residential proxies and VPN exit nodes are common in these attacks.
Geolocation — flag IPs from regions inconsistent with the user’s usual access pattern.
TTPs
From the TTPs tab, add the techniques observed:
T1110.004 Credential Stuffing — automated login attempts using leaked username and password pairs.
T1078 Valid Accounts — successful use of a legitimate account after takeover.
T1133 External Remote Services — attack targeting a VPN or remote access portal.
T1586 Compromise Accounts — use of credentials obtained from a third-party breach to gain access.
T1539 Steal Web Session Cookie — if post-compromise session hijacking was detected.
Close the case
After all tasks are complete, click Close case. Select:
True Positive — at least one account was taken over by the attacker.
False Positive — all login attempts failed; no account was compromised.
Indeterminate — a suspicious login succeeded but authorisation cannot be confirmed or denied.
Set Impact to Yes if a confirmed takeover granted access to customer data, OT system documentation, or internal resources. Enter a Summary listing the number of accounts targeted, accounts compromised, source IPs blocked, and any data the attacker may have accessed during the active session.