Lesson 26 — The Same IP Address Touched Five Accounts
The first alert looked like a normal failed sign-in.
Then the same source IP appeared against another user. And another.
Within twelve minutes, five different identities had been touched.
One account eventually showed a successful sign-in.
Now the analyst was no longer investigating a single user's authentication problem.
The useful pivot had changed from the account to the source IP address.
Five accounts. One source.
The analyst must determine whether the IP represents legitimate shared infrastructure, a VPN or proxy, password spraying, credential testing or a broader identity compromise.
Case briefing
Investigation objective
Determine how many identities were contacted by the source, which attempts failed or succeeded, whether the pattern matches normal shared infrastructure and whether any successful session requires containment.
Investigator's rule
A useful pivot can change during an investigation. Once the same IP appears across multiple users, the source itself becomes an entity worth investigating.
Stage 1 — recognise the pattern
| Observation | Possible meaning |
|---|---|
| One IP, one user | Normal authentication, user-specific attack or isolated anomaly. |
| One IP, many users | Shared network, proxy, VPN, password spray or coordinated credential testing. |
| Many failures, no success | Attempted attack may have been unsuccessful — but scope still matters. |
| Many failures, then success | Potential credential compromise requiring immediate investigation. |
| Privileged account included | Impact and urgency increase even if the overall pattern is unchanged. |
Do not label it too early
Several users behind a corporate NAT gateway can legitimately share one public IP. A VPN exit node can do the same. The pattern is suspicious evidence, not automatic proof of password spraying.
Success changes the investigation
If four attempts failed but the fifth succeeded, prioritise the successful identity while continuing to scope the other accounts touched by the source.
Stage 2 — pivot from the IP with KQL
Search Microsoft Entra sign-in telemetry for every identity associated with the source during the investigation window.
let SuspiciousIP = "203.0.113.74";
SigninLogs
| where TimeGenerated > ago(24h)
| where IPAddress == SuspiciousIP
| project TimeGenerated,
UserPrincipalName,
AppDisplayName,
ResultType,
ResultDescription,
ConditionalAccessStatus,
AuthenticationRequirement,
Location,
DeviceDetail
| order by TimeGenerated asc
Build the identity list
Record every user touched by the source, not only the user from the original alert. That list defines the initial scope of the identity incident.
Preserve the sequence
Order events by time. A rapid sequence across usernames can tell a different story from several unrelated sign-ins spread across an entire day.
Stage 3 — summarise the source behaviour
Count distinct identities, successes and failures so the scale of the pattern is visible immediately.
let SuspiciousIP = "203.0.113.74";
SigninLogs
| where TimeGenerated > ago(24h)
| where IPAddress == SuspiciousIP
| summarize
Attempts=count(),
Accounts=dcount(UserPrincipalName),
Users=make_set(UserPrincipalName, 50),
FirstSeen=min(TimeGenerated),
LastSeen=max(TimeGenerated),
SuccessfulSignIns=countif(ResultType == 0),
FailedSignIns=countif(ResultType != 0)
by IPAddress
Count users, not just events
Two hundred failed events against one account is a different pattern from two hundred attempts distributed across fifty accounts. Both matter, but the attack hypothesis changes.
Result codes need context
Use the sign-in result and description together. Not every non-zero result means “bad password,” and different failure reasons can reveal how far authentication progressed.
Stage 4 — separate the successful accounts
A successful account becomes the priority pivot
Once one identity authenticates successfully, investigate that user's MFA, Conditional Access, device, application and post-authentication activity immediately.
Do not forget the failed accounts
Users that only show failures may still need password resets, risk review or monitoring depending on the evidence and organisational response process.
Stage 5 — test the shared-infrastructure explanation
| Evidence | Benign interpretation | Suspicious interpretation |
|---|---|---|
| IP belongs to corporate egress | Many employees legitimately share the address. | Compromised internal host or abused corporate access path. |
| Known VPN provider | Users are travelling or working remotely. | Attacker is hiding source through commercial VPN infrastructure. |
| Rapid usernames | Automated legitimate service in rare cases. | Password spraying or credential testing. |
| Different countries from user baseline | Travel or network routing. | Source inconsistent with expected user behaviour. |
| One eventual success | Legitimate user corrected credentials. | Attacker found a valid credential or satisfied authentication. |
Reputation is supporting evidence
IP reputation can help, but it should not replace telemetry. A “clean” address can still be malicious, and a previously suspicious address may be shared by many unrelated users.
Identity criticality still matters
If the source touched a Global Administrator, finance executive or service account, elevate the investigation priority even before a successful sign-in is confirmed.
Stage 6 — look for the spray pattern
Attackers may stay below thresholds
Password spraying often avoids hammering one account repeatedly. A low number of attempts spread across many identities can be more revealing than the count for any single user.
Expand the time window carefully
If the twelve-minute cluster looks suspicious, widen the search to hours or days. The same source may have tested additional identities before the first alert appeared.
Stage 7 — make the SOC decision
Write the investigation finding
Lesson 26 key takeaways
- When one IP touches multiple accounts, pivot from the individual user to the shared source.
- Enumerate every identity associated with the source during the investigation window.
- Preserve event order because rapid cross-account activity can reveal coordinated behaviour.
- Use KQL to count distinct accounts, successes, failures and the first and last observed events.
- A successful sign-in should immediately become a priority investigation path.
- Failed accounts remain part of the incident scope.
- Corporate NAT, VPNs and proxies can legitimately produce one-IP-to-many-user patterns.
- Password spraying often uses few attempts per account across many identities.
- IP reputation is supporting context, not a security verdict.
- The strongest SOC investigations connect alerts through shared entities instead of treating each alert separately.
Module 3 — Identity Incidents
Lesson 26 shows how a shared source can connect several authentication events into one identity incident. Next, Agent Foskett investigates a successful sign-in where the resulting session behaves nothing like the user.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 3: Identity Incidents
How to investigate one IP address across multiple Microsoft Entra accounts
Lesson 26 of the Agent Foskett SOC Analyst Academy teaches analysts how to pivot from a shared source IP, enumerate affected identities, distinguish successful and failed authentication and test whether the pattern represents shared infrastructure or coordinated identity attack activity.
KQL investigation of password spraying and multi-account sign-ins
Learn how to use Microsoft Entra SigninLogs with KQL to identify distinct users associated with one IP address, summarise authentication outcomes and investigate possible password spraying or credential testing.
