Agent Foskett Academy • KQL Academy • Module 11 • Lesson 136

Lesson 136 — The Same IP Address Touched Five Accounts

One unfamiliar source IP appeared in a sign-in investigation.

At first, it looked like a single-user problem. Then the analyst pivoted on the IP address and discovered something more interesting: the same source had touched five different accounts.

This lesson teaches you how to move from one identity to a broader authentication pattern. We will use SigninLogs to count targeted users, measure failed and successful attempts, group activity into short windows and decide whether the evidence is more consistent with shared infrastructure, user behaviour, automated credential testing or a possible password spray attack.

The first account gave us the clue. The IP address showed us the campaign.

Start Lesson 136 Back to KQL Academy

Agent Foskett KQL Academy multi-account source IP investigation

What you will investigate

One source IP generating authentication activity across multiple Microsoft Entra identities.

✓ Pivot from one IP to many users

✓ Count failures and successes

✓ Measure short authentication bursts

✓ Test password-spray hypotheses

The investigation begins

09:11 UTC ↓ One user has repeated sign-in failures ↓ The source IP looks unfamiliar ↓ The analyst pivots on IPAddress ↓ A second user appears ↓ Then a third ↓ Then a fourth ↓ Then a fifth ↓ QUESTION Are five users legitimately sharing one source... or is one source testing credentials across five identities?

Learning objectives

Use KQL to pivot from a suspicious source IP across multiple users, identify concentrated authentication activity, separate failures from successes, measure time-based bursts and build an evidence-based hypothesis about coordinated credential activity.

Why this matters

Password spray and other credential attacks often become clearer when you stop looking at one user. A source that seems unremarkable against a single account can become highly interesting when the same infrastructure repeatedly touches many identities.

Step 1 — pivot on the source IP

Start with the IP address from the original investigation and simply list every sign-in event associated with it.

12345678910111213

let TargetIP = "203.0.113.42";
SigninLogs
| where TimeGenerated > ago(24h)
| where IPAddress == TargetIP
| project TimeGenerated,
          UserPrincipalName,
          AppDisplayName,
          Location,
          ResultType,
          ResultDescription,
          ConditionalAccessStatus,
          AuthenticationRequirement
| order by TimeGenerated asc

Do not call it an attack yet

One public IP can legitimately represent an office gateway, VPN concentrator, secure access service, mobile carrier or other shared infrastructure. Multiple users behind one IP are not automatically suspicious.

Look at who and how

The useful question is not only how many users appeared. Look at the sequence, applications, failures, successes, location and authentication context. Shared legitimate traffic usually tells a different story from concentrated failed credential attempts.

Step 2 — find IPs touching many identities

Now widen the hunt across the tenant. dcount(UserPrincipalName) tells us how many distinct identities each source IP touched.

12345678910

SigninLogs
| where TimeGenerated > ago(24h)
| summarize AttemptCount=count(),
            UserCount=dcount(UserPrincipalName),
            Users=make_set(UserPrincipalName, 25),
            Apps=make_set(AppDisplayName, 15),
            Locations=make_set(Location, 10)
          by IPAddress
| where UserCount >= 5
| order by AttemptCount desc

Five users is a hunting threshold

The value five is only an exploratory threshold for this lesson. It is not a universal password-spray rule. Tune the number against the size and network architecture of your environment.

Context can immediately explain some results

An IP associated with a known corporate egress point may legitimately touch hundreds of users. A residential, hosting or unfamiliar network touching five accounts in a short window may deserve much more attention.

Step 3 — measure failures and successes per user

For the source under investigation, summarize the activity account by account. This helps expose whether the source is failing repeatedly against many users and whether any account eventually succeeds.

1234567891011

let TargetIP = "203.0.113.42";
SigninLogs
| where TimeGenerated > ago(24h)
| where IPAddress == TargetIP
| summarize AttemptCount=count(),
            FailureCount=countif(ResultType != "0"),
            SuccessCount=countif(ResultType == "0"),
            FirstSeen=min(TimeGenerated),
            LastSeen=max(TimeGenerated)
          by UserPrincipalName
| order by FailureCount desc, SuccessCount desc

Why success matters so much

A spray attempt containing only failures may still represent hostile activity. But a successful sign-in from the same source after repeated failures can change the incident priority because the investigation may now involve actual account access.

Failure patterns differ

Password spray is typically broad rather than deeply repetitive against one account. Brute-force activity may hammer fewer identities with many attempts. KQL lets you see the shape rather than force every pattern into one label.

Step 4 — group the activity into ten-minute windows

Concentrated bursts are easier to see when events are grouped into short windows.

12345678910

let TargetIP = "203.0.113.42";
SigninLogs
| where TimeGenerated > ago(24h)
| where IPAddress == TargetIP
| summarize AttemptCount=count(),
            FailureCount=countif(ResultType != "0"),
            SuccessCount=countif(ResultType == "0"),
            Users=dcount(UserPrincipalName)
          by bin(TimeGenerated, 10m)
| order by TimeGenerated asc

Why time changes the interpretation

Five users touching one office NAT address over twelve hours may be normal. Five different accounts failing from the same unfamiliar IP within ten minutes can be much more significant.

Automated activity often has rhythm

Attack tooling can create regular or concentrated patterns. Human activity often has more variation. Timing alone is not proof, but it becomes useful supporting evidence when paired with user count and failure behaviour.

Step 5 — isolate successful accounts

Now ask the question that changes the investigation: did this source successfully authenticate any of the targeted identities?

1234567891011

let TargetIP = "203.0.113.42";
SigninLogs
| where TimeGenerated > ago(24h)
| where IPAddress == TargetIP
| where ResultType == "0"
| summarize SuccessfulUsers=make_set(UserPrincipalName, 25),
            SuccessCount=count(),
            Apps=make_set(AppDisplayName, 15),
            Locations=make_set(Location, 10)
          by IPAddress
| order by SuccessCount desc

A success is the pivot, not the conclusion

If one user succeeds, immediately compare that event with the user's normal IPs, device, location, application, Conditional Access result and authentication method. The same source IP may have reached an account — or the success may have a legitimate explanation.

Success after broad failures deserves priority

When one source produces failures across several users and then succeeds against one of them, the investigation should escalate. The pattern may indicate that one credential in the tested set worked.

Step 6 — build the full source-IP timeline

Finish by laying every event from the source into one chronological sequence. This is where the campaign becomes visible.

12345678910111213141516

let TargetIP = "203.0.113.42";
SigninLogs
| where TimeGenerated > ago(24h)
| where IPAddress == TargetIP
| project TimeGenerated,
          UserPrincipalName,
          ResultType,
          ResultDescription,
          AppDisplayName,
          ResourceDisplayName,
          Location,
          ClientAppUsed,
          IsInteractive,
          ConditionalAccessStatus,
          AuthenticationRequirement
| order by TimeGenerated asc

Read horizontally across identities

Identity investigations often begin vertically: everything about one user. This lesson adds another technique — read horizontally across users to see whether infrastructure, timing or application behaviour connects them.

Microsoft can detect password spray too

Microsoft Entra ID Protection includes password spray as a risk detection, and Microsoft Defender guidance provides a dedicated password-spray investigation workflow. KQL hunting still matters because it lets analysts test their own evidence, investigate related accounts and reconstruct the sequence independently.

Evidence table

Observation	What it suggests	What it does not prove
One IP touches five accounts	The identities share a network source.	That the source is malicious.
Five users fail in ten minutes	Concentrated multi-user authentication activity.	That it is definitely password spray.
Known office egress IP	The source may be legitimate shared infrastructure.	That every event from it is trusted.
Unfamiliar hosting/residential source	The network context deserves investigation.	That an attacker controls it.
Failures across many users	Possible broad credential testing.	Which attack technique is being used without more evidence.
One user succeeds after broad failures	The source obtained successful access to an identity.	That the successful session was malicious without user context.

Agent Foskett's investigation

09:11 User A fails authentication ↓ Same source IP ↓ User B fails ↓ User C fails ↓ User D fails ↓ User E fails ↓ KQL counts five distinct identities ↓ The activity is grouped into ten-minute windows ↓ The failures form a concentrated burst ↓ Then User C succeeds ↓ The successful event is compared with User C's baseline ↓ The IP is new ↓ The device context is unfamiliar ↓ The investigation expands from suspicious authentication ↓ to possible credential compromise

The source IP mattered because it connected five separate identity stories into one investigation.

Investigation questions to ask next

Is the source IP known corporate, VPN or secure-access infrastructure?
How many distinct users did the IP touch?
How tightly clustered were the attempts?
Were the failures spread broadly across users or concentrated against one account?
Did any account successfully authenticate?
Did the successful account use a new device or location?
Which applications and resources were targeted?
Did multiple users receive MFA prompts?
Does Entra ID Protection show password-spray or other risk detections?
What did the successful identity do after authentication?

Lesson 136 key takeaways

Pivoting on infrastructure can expose relationships hidden in single-user investigations.
Use dcount(UserPrincipalName) to measure how many identities a source touched.
Multi-user IP activity can be legitimate shared infrastructure.
Failures, successes and timing must be interpreted together.
Short time windows can expose concentrated authentication bursts.
Password spray is broad credential testing, but not every broad failure pattern is spray.
A successful account after widespread failures deserves immediate attention.
Compare any success with the user's normal identity baseline.
Read identity telemetry horizontally across users as well as vertically within one user.
The strongest conclusion comes from source, timing, account count and authentication outcome together.

Continue your KQL investigation training

Lesson 136 continues Module 11: Identity Threat Hunting. Next we examine a successful sign-in whose session behaviour does not match the identity that authenticated.

KQL Academy Lesson 135 — The Privileged Role Became Active at 2:07 AM Microsoft Entra Security Academy Agent Foskett Academy

Related Agent Foskett Investigations

Continue the identity investigation with cases involving suspicious authentication, unusual source behaviour and the evidence needed to distinguish alerts from actual compromise.

The Attacker Logged In After MFA The Login Was Successful But The Risk Was High Impossible Travel Sign-In Investigation Browse Agent Foskett Investigations

🔎 KQL Academy — Module 11: Identity Threat Hunting

Use KQL to investigate identity behaviour as evidence.

⬅ Previous lesson

Lesson 135 — The Privileged Role Became Active at 2:07 AMCorrelate privileged role activity with sign-ins and surrounding identity evidence.

✅ Current lesson

Lesson 136 — The Same IP Address Touched Five AccountsPivot from one source IP across several identities and investigate coordinated authentication activity.

Next lesson

Lesson 137 — The Sign-In Was Successful but the Session Wasn't NormalInvestigate what happens after authentication when the session no longer fits the user's expected behaviour.

Investigate one IP address across multiple Microsoft Entra accounts with KQL

Lesson 136 of the Agent Foskett KQL Academy teaches analysts how to pivot on source IP addresses in SigninLogs, count distinct users, measure authentication failures and successes, identify short multi-user bursts and investigate possible password spray activity.

Microsoft Entra password spray and multi-account sign-in investigation

A source IP touching several identities can represent legitimate shared infrastructure or coordinated credential testing. KQL helps analysts combine user count, timing, authentication outcomes, applications and identity context before deciding what the evidence supports.