Location can look familiar while the network behind an IP address is completely different from the infrastructure a user normally authenticates through.
✓ Preserve the location and source IP
✓ Compare the autonomous system number
✓ Scope other accounts and IPs on the same network
Australia looked normal
The affected user normally worked in Australia, and the sign-in location also resolved to Australia. A country-only review therefore produced no obvious anomaly. But country is only one attribute of a source IP. The network operating that address can provide another layer of context.
Country matchedThe sign-in did not originate from an unexpected country.
No impossible travelThere was no dramatic geographic jump to attract attention.
Network context remainedThe IP address and autonomous system still needed to be compared with normal behaviour.
Keep the ASN beside the location
In Microsoft Sentinel, SigninLogs can include AutonomousSystemNumber. Keep that value beside the source IP and location fields. The ASN identifies the autonomous system associated with the address and gives the analyst another stable network pivot beyond country and city.
signin-location-and-asn.kql
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
let User = "alex@contoso.com";
SigninLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName =~ User
| extend Country = tostring(LocationDetails.countryOrRegion),
State = tostring(LocationDetails.state),
City = tostring(LocationDetails.city)
| project TimeGenerated,
UserPrincipalName,
AppDisplayName,
IPAddress,
Country,
State,
City,
AutonomousSystemNumber,
ResultType,
ConditionalAccessStatus
| order by TimeGenerated desc
Follow the exact source IP
Before widening to the ASN, investigate the exact IP address. Determine which accounts used it, which applications were targeted, whether the attempts succeeded and how Conditional Access evaluated the activity.
source-ip-signins.kql
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
let SuspiciousIP = "203.0.113.25";
SigninLogs
| where TimeGenerated > ago(30d)
| where IPAddress == SuspiciousIP
| project TimeGenerated,
UserPrincipalName,
AppDisplayName,
IPAddress,
AutonomousSystemNumber,
ResultType,
ResultDescription,
ConditionalAccessStatus
| order by TimeGenerated asc
The ASN changed the context
The user's familiar sign-ins normally came through a different set of networks. The Australian location therefore remained true, but it was incomplete. The unusual ASN created a new question: was this a legitimate change in connectivity, or infrastructure that deserved wider investigation?
Country: AustraliaThe geographic label matched the user's expected region.
ASN: unfamiliarThe autonomous system did not match the user's established sign-in pattern.
Verdict: investigateThe network mismatch was a reason to gather more evidence, not automatic proof of compromise.
What is the ASN doing across the tenant?
Scope the autonomous system across Entra sign-ins. A network associated with one unusual event may also appear against other users and applications. Summarising successes, failures, users and IPs helps establish whether the activity is isolated or widespread.
asn-tenant-scope.kql
1
2
3
4
5
6
7
8
9
10
11
12
13
let SuspiciousASN = 64500;
SigninLogs
| where TimeGenerated > ago(30d)
| where AutonomousSystemNumber == SuspiciousASN
| summarize SignIns=count(),
Users=dcount(UserPrincipalName),
IPs=dcount(IPAddress),
Successful=countif(ResultType == 0),
Failed=countif(ResultType != 0)
by AppDisplayName
| order by SignIns desc
Which accounts did the network touch?
Now pivot from applications to identities. If the same ASN is associated with authentication attempts against multiple accounts, the pattern may deserve greater scrutiny. Equally, widespread legitimate use can explain why the ASN appears across many users.
asn-account-scope.kql
1
2
3
4
5
6
7
8
9
10
11
12
13
let SuspiciousASN = 64500;
SigninLogs
| where TimeGenerated > ago(30d)
| where AutonomousSystemNumber == SuspiciousASN
| summarize SignIns=count(),
Successful=countif(ResultType == 0),
FirstSeen=min(TimeGenerated),
LastSeen=max(TimeGenerated),
IPs=make_set(IPAddress, 20)
by UserPrincipalName
| order by SignIns desc
Compare the user with their own history
The strongest baseline is often the user's own previous behaviour. Summarise the account's sign-ins by day, country and ASN to see whether the network is genuinely new or simply an infrequent but legitimate part of the user's normal connectivity.
user-asn-history.kql
1
2
3
4
5
6
7
8
9
10
11
12
13
14
let User = "alex@contoso.com";
SigninLogs
| where TimeGenerated > ago(30d)
| where UserPrincipalName =~ User
| extend Country = tostring(LocationDetails.countryOrRegion)
| summarize SignIns=count(),
Successful=countif(ResultType == 0),
IPs=dcount(IPAddress)
by bin(TimeGenerated, 1d),
Country,
AutonomousSystemNumber
| order by TimeGenerated asc
Build the network timeline
An ASN can contain many IP addresses. Summarise the individual addresses observed over time to understand whether the activity came from one stable source or rotated across multiple addresses within the same autonomous system.
asn-ip-timeline.kql
1
2
3
4
5
6
7
8
9
10
11
12
13
14
let SuspiciousASN = 64500;
SigninLogs
| where TimeGenerated > ago(30d)
| where AutonomousSystemNumber == SuspiciousASN
| summarize FirstSeen=min(TimeGenerated),
LastSeen=max(TimeGenerated),
SignIns=count(),
Users=dcount(UserPrincipalName),
Successful=countif(ResultType == 0),
Failed=countif(ResultType != 0)
by IPAddress
| order by FirstSeen asc
ASN evidence needs interpretation
An ASN is a network-routing identifier, not a maliciousness verdict. Consumer ISPs, mobile carriers, enterprises, VPN providers, hosting companies and cloud platforms can all operate autonomous systems. The value comes from comparing the network with expected user behaviour and the rest of the authentication evidence.
CountryProvides useful geographic context, but can be too broad on its own.
ASNProvides another way to group and compare the network behind sign-in IP addresses.
User baselineHelps determine whether that network is normal for the specific identity.
What the evidence can and cannot prove
A different ASN can prove that a sign-in came through a different autonomous system from the user's usual network. It cannot, by itself, prove that the address was attacker-controlled, a VPN, a proxy or malicious hosting. Those conclusions require additional evidence or external IP intelligence.
ProvenThe sign-in's IP and ASN can be compared with the user's historical sign-in telemetry.
InvestigateOther accounts, applications, results and Conditional Access outcomes provide additional context.
Do not overclaimAn unfamiliar ASN is an anomaly to explain, not automatic proof of compromise.
Agent Foskett's investigation mindset
Do not stop at the most human-readable field. “Australia” feels reassuring because it matches the user's country, but the underlying IP still belongs to a network that can be compared, scoped and baselined. The location is part of the story. It is not the whole story.
Start with geographyUse country, state and city as initial context.
Go deeper into the networkPreserve the IP and autonomous system number.
Compare behaviourDecide whether the network fits the user and tenant history.
Investigation findings
The sign-in's Australian location was accurate, but location alone did not explain whether the activity was expected. The source IP belonged to an autonomous system that differed from the user's established sign-in pattern. Scoping that ASN across the tenant, reviewing the accounts and applications involved, and comparing the user with their own historical network activity provided the context needed for a defensible verdict.
The country matchedThere was no obvious geographic anomaly.
The network differedThe ASN created a more subtle behavioural anomaly.
The baseline matteredHistorical sign-in behaviour determined whether the difference was meaningful.
Related Agent Foskett investigations
Continue with Microsoft Entra sign-in, IP and identity investigations.
A sign-in from the right country can still deserve investigation. Geography answers one question about an IP address. It does not tell you whether that network is normal for the user, whether the same infrastructure touched other identities or whether the authentication pattern changed. When the country looks familiar, keep investigating the network underneath it.
Where did it come from?Start with location and the exact source IP.
Which network was behind it?Use the ASN as another investigative pivot.
Was that normal?Compare the network with the user's own sign-in history before reaching a verdict.
Develop IT. Protect IT. GEMXIT PTY LTD | GEMXIT UK LTD
The Sign-In Came From Australia — The ASN Told a Different Story
This Agent Foskett investigation explores Microsoft Entra ID sign-in location, source IP addresses, AutonomousSystemNumber, Conditional Access and KQL.
Microsoft Entra ASN Investigation
The investigation begins with an Australian sign-in that looks geographically normal and then compares the autonomous system behind the source IP with the user's historical authentication behaviour.
SigninLogs, IP Addresses, ASN And KQL
Country and city are useful context, but network evidence can reveal subtler differences. ASN and source-IP scoping help defenders understand whether a sign-in fits the identity's established pattern.