ACSC Logo
© GEMXIT
GEMXIT Logo
Agent Foskett Case File • Microsoft Sentinel • Watchlists • SigninLogs • Reference Data • Detection Engineering • KQL

The Watchlist Said Trusted — The IP Wasn't

The sign-in looked suspicious.

A privileged account.
An unusual location.
An IP address nobody on the SOC recognised.

But the detection did not fire.

Why?

The source IP matched an entry in the organisation's trusted-IP watchlist.

That should have ended the investigation.

It didn't.

Agent Foskett asked the question the allowlist could not answer.

Was the IP still trusted — or was the watchlist simply out of date?

Discuss Microsoft SecurityBack to investigations
Agent Foskett investigating stale trusted IP data in a Microsoft Sentinel watchlist
The Watchlist Matched. Reality Didn't.

Reference data can reduce noise and enrich detections. But an allowlist is only as trustworthy as the process that keeps it current.

✓ Confirm the watchlist match
✓ Validate the trusted-IP ownership
✓ Hunt activity suppressed by the exception

The alert that never appeared

The investigation began with a sign-in discovered during a separate review.

The account was privileged. The source address was unusual. The timing deserved attention.

Yet the expected Sentinel analytics rule had produced no alert.

Agent Foskett reviewed the rule logic and found the reason.

Events from IP addresses in the trusted-IP watchlist were excluded.

Watchlists are reference data — not evidence of trust

Microsoft Sentinel watchlists are designed to correlate and enrich event data. They can contain IP addresses, users and other business reference data, and they can also be used to manage exceptions in analytics rules.

That makes them useful.

It also means a bad assumption in a watchlist can influence multiple detections at once.

The watchlist did not prove the IP was safe. It proved somebody had previously classified it as trusted.

Confirm the watchlist entry

Agent Foskett queried the watchlist directly. Microsoft Sentinel exposes watchlist content through _GetWatchlist(), and Microsoft recommends using the configured SearchKey for joins and frequent searches.
trusted-ip-watchlist.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
_GetWatchlist('TrustedIPs')
| project SearchKey,
          IPAddress = tostring(WatchlistItem.IPAddress),
          Owner = tostring(WatchlistItem.Owner),
          Purpose = tostring(WatchlistItem.Purpose),
          ReviewDate = tostring(WatchlistItem.ReviewDate)
| where SearchKey == "203.0.113.25"

The IP really was on the list

The result confirmed the detection had behaved exactly as designed.

The source address matched the allowlist.

But the metadata beside it told a different story.

The entry referred to an old supplier connection. The service had been retired months earlier, and the organisation could no longer establish a current business reason for trusting the address.

The detection was not broken. The assumption feeding the detection was stale.

Do not use TimeGenerated as the business review date

Agent Foskett noticed another trap.

Microsoft Sentinel refreshes watchlists periodically and updates the underlying TimeGenerated field. That timestamp therefore should not be treated as proof that somebody recently reviewed or re-approved the business meaning of an entry.

If trust needs an expiry or review date, store that governance information explicitly in the watchlist data or its source-of-truth process.

A refreshed record is not the same thing as a revalidated exception.

Show which sign-ins matched the trusted list

Next, Agent Foskett correlated the trusted-IP watchlist with Microsoft Entra sign-in telemetry. Using SearchKey as the watchlist join key makes the relationship explicit.
trusted-ip-signins.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
let TrustedIPs =
    _GetWatchlist('TrustedIPs')
    | project SearchKey;
SigninLogs
| where TimeGenerated > ago(30d)
| lookup kind=leftouter TrustedIPs
    on $left.IPAddress == $right.SearchKey
| extend TrustedByWatchlist = isnotempty(SearchKey)
| where TrustedByWatchlist
| project TimeGenerated,
          UserPrincipalName,
          IPAddress,
          AppDisplayName,
          ResultType,
          ConditionalAccessStatus
| order by TimeGenerated desc

One stale entry could hide more than one event

The investigation was no longer about a single sign-in.

If the trusted IP had been stale for weeks or months, every rule using that same watchlist exception could have treated activity from the address differently.

Agent Foskett identified the exposure window and searched the retained telemetry for all activity associated with the address.

When an exception is wrong, investigate the period in which the exception was trusted.

Hunt the stale IP directly

Once the trust classification was challenged, Agent Foskett stopped excluding the address and hunted it directly across the available sign-in history.
stale-trusted-ip-hunt.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
let SuspiciousIP = "203.0.113.25";
SigninLogs
| where TimeGenerated > ago(30d)
| where IPAddress == SuspiciousIP
| project TimeGenerated,
          UserPrincipalName,
          AppDisplayName,
          IPAddress,
          Location,
          ResultType,
          ConditionalAccessStatus,
          CorrelationId
| order by TimeGenerated asc

The watchlist had become part of the attack surface

The attacker did not need to modify the analytics rule.

They did not need to disable Microsoft Sentinel.

They simply benefited from a detection exception the organisation had failed to maintain.

That distinction matters because allowlists are often treated as operational housekeeping rather than security controls.

Anything capable of suppressing or changing detection behaviour deserves security governance.

Was the entry stale — or had somebody changed it?

Agent Foskett did not assume neglect was the only explanation.

He checked the watchlist's management history and the organisation's source process to determine whether the IP had simply remained too long, had been added incorrectly, or had been deliberately introduced as an exception.

The current watchlist entry answered what Sentinel was using now.

The management trail and business records were needed to explain why it was there.

Bad reference data can come from error, weak governance or deliberate tampering.

Fixing the watchlist was only the first response

Removing the stale IP restored the intended detection behaviour going forward.

It did not answer what had happened while the address was trusted.

Agent Foskett therefore treated remediation and investigation as separate tasks.

Fix the exception. Then hunt the exception window.

Build the watchlist investigation timeline

Suspicious sign-in discoveredAn event is found that should have deserved detection or investigation.
Detection exception identifiedThe source IP matches a trusted-IP watchlist used by the analytics logic.
Business trust challengedThe organisation can no longer validate the reason the IP is trusted.
Exposure window definedThe period during which the stale exception could influence detections is established.
Historical activity huntedSign-ins and other telemetry from the IP are reviewed without the allowlist assumption.
Governance correctedThe stale entry is removed and ownership, review and expiry controls are strengthened.

What Agent Foskett checked

SearchKeyWhich field actually drives the watchlist correlation?
Business ownerWho is responsible for validating the trusted entry?
PurposeWhy was the IP originally allowlisted?
Review dateWhen was the business justification last independently validated?
Detection dependenciesWhich analytics and hunting queries consume the watchlist?
Historical activityWhat happened while the stale exception could affect detection?

What the evidence can and cannot prove

A match returned by _GetWatchlist() proves that the queried value is present in the current watchlist data available to Sentinel.

It does not prove the value is still trustworthy in the real world.

Likewise, finding suspicious activity from an allowlisted IP does not by itself prove that the watchlist was maliciously altered.

Separate the technical match, the business justification and the history of how the exception was maintained.

The lesson

The analytics rule had done what it was told.

The IP matched the trusted list, so the event was excluded.

The problem was that reality had moved on while the exception had not.

A watchlist is reference data. It is not a permanent certificate of trust.

If a watchlist can suppress detections, its entries need owners, justification, review and expiry just like any other security exception.
Investigation principle: When a detection excludes an event because of reference data, validate the reference data independently before accepting the exclusion as benign.

Related investigations

Agent Foskett InvestigationsContinue through the complete collection of real-world Microsoft security investigations.KQL Threat HuntingUse KQL to investigate identity, endpoint, cloud and detection-engineering evidence.SOC Analyst AcademyBuild practical investigation, triage and detection skills across Microsoft security platforms.
The watchlist matched. Reality didn't.
Validate the exception. Define the exposure window. Hunt what the allowlist hid.
Continue the Investigation

Final thought

Allowlists make security operations manageable.

Without exceptions, analysts can drown in known and expected activity.

But every exception creates an assumption.

And assumptions age.

The IP was trusted yesterday.

That did not make it trusted forever.

Agent Foskett followed the event the rule had ignored, challenged the reference data and rebuilt the missing timeline.

The Logs Already Knew! 🔎
Develop IT.. Protect IT.. GEMXIT.
GEMXIT PTY LTD | GEMXIT UK LTD
Talk to GEMXIT
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT

The Watchlist Said Trusted — The IP Wasn't

This Agent Foskett investigation examines stale trusted-IP reference data in a Microsoft Sentinel watchlist and how an outdated allowlist entry can affect detection logic.

Investigating Microsoft Sentinel Watchlist Exceptions

Use _GetWatchlist, SearchKey, SigninLogs and KQL to validate trusted-IP matches, identify stale exceptions and hunt activity that may have been excluded from analytics rules.

Trusted IP Watchlists and Detection Engineering

Learn why allowlists require ownership, business justification, review and expiry, and why a technical watchlist match should not be treated as permanent proof that an IP address remains trustworthy.