Agent Foskett • Entra ID • Trusted Device Investigation

The Login Came Through A Trusted Device

The sign-in looked legitimate.

Correct user. Correct MFA. Correct device. Conditional Access allowed it.

Everything matched policy.

The problem was...

the attacker was already inside the trusted device.

This Agent Foskett briefing looks at a modern Microsoft security problem: attackers do not always need to bypass identity controls if they can inherit trust from a device that the organisation already trusts.

The dashboard may show a successful login. The Conditional Access policy may show success. The device may appear compliant. But the real investigation begins after trust has been granted.

Discuss your environment Back to briefings

Agent Foskett trusted device Entra ID investigation

Briefing summary

A trusted device is not automatically a safe device. GEMXIT looks at how Entra ID sign-ins, Conditional Access, Microsoft Defender for Endpoint and KQL can reveal suspicious behaviour after a legitimate authentication event.

Investigate trusted-device abuse

Correlate identity and endpoint telemetry

Validate behaviour after authentication

What happened

A successful Entra ID sign-in came through a corporate device that had already been trusted by the organisation. The login passed normal checks, but the behaviour around the login did not fit.

The sign-in looked legitimate The user authenticated successfully. MFA was satisfied. Conditional Access did not block the session because the device matched the expected trust conditions.

The device was already compromised The endpoint still appeared trusted, but suspicious browser, process or session behaviour suggested that malware or remote access may have been present.

The attacker inherited trust The risk was not a failed security control. The risk was that the attacker operated through an identity and device combination the environment already trusted.

The problem with device trust assumptions

Device compliance is important, but compliance does not prove that a device is uncompromised. It proves the device meets policy requirements at a point in time.

Compliant does not mean clean A device may be encrypted, managed and compliant while still containing stolen browser tokens, malicious processes or unauthorised remote access.

Allowed does not mean safe Conditional Access can allow a session for valid reasons. The investigation still needs to ask whether the activity after access was granted makes sense.

Timing still matters Trusted-device activity at unusual hours, unusual volume or unusual application patterns may be more important than the sign-in result itself.

First hunt: successful sign-ins from trusted devices

A successful sign-in is not the end of the investigation. Start by finding successful authentication from trusted devices and reviewing volume, IP address, application and device patterns.

SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| summarize LoginCount = count(),
            Apps = make_set(AppDisplayName),
            IPs = make_set(IPAddress),
            Locations = make_set(Location)
            by UserPrincipalName, DeviceDetail, bin(TimeGenerated, 1d)
| where LoginCount > 20
| order by LoginCount desc

What to review Look for sudden increases in successful sign-ins, unusual IP spread, unexpected application access or successful sessions outside normal behaviour.

Why it matters Compromised sessions often appear as successful authentication events, not failed login attempts.

Best next pivot Pivot into Conditional Access results, device details, MFA claims, session age, token behaviour and Defender endpoint telemetry.

Second hunt: endpoint activity before or after the trusted login

If a trusted device is suspected, endpoint telemetry becomes critical. Look for suspicious process activity, script hosts, browser launches and living-off-the-land behaviour around the sign-in window.

DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "cmd.exe", "wscript.exe", "mshta.exe", "rundll32.exe")
   or InitiatingProcessFileName in~ ("chrome.exe", "msedge.exe", "firefox.exe")
| project Timestamp,
          DeviceName,
          InitiatingProcessAccountName,
          FileName,
          ProcessCommandLine,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine
| order by Timestamp desc

What to review Look for encoded commands, unusual parent processes, script hosts launched by browsers, suspicious command lines and unexpected user context.

Why it matters Infostealers, remote access tools and browser session theft often leave endpoint traces before the identity event becomes suspicious.

Best next pivot Pivot into DeviceNetworkEvents, file creation, browser credential access, Defender alerts and any unusual cloud activity after authentication.

Third hunt: suspicious cloud activity after trust was granted

When the login itself looks normal, the best evidence may appear in what happens after the session begins: files accessed, data downloaded, mailbox changes or unusual administrative actions.

AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName has_any ("FileDownloaded", "Add member", "Update user", "Consent")
| extend Hour = datetime_part("hour", TimeGenerated)
| where Hour < 6 or Hour > 20
| project TimeGenerated,
          OperationName,
          InitiatedBy,
          TargetResources
| order by TimeGenerated desc

What to review Look for data access, file downloads, permission changes, application consent and mailbox activity that follows a trusted login.

Why it matters Attackers who inherit trust often move straight into data access, persistence, mailbox changes or cloud privilege abuse.

Best next pivot Pivot into Microsoft Defender for Cloud Apps, Microsoft Purview audit, SharePoint activity, mailbox rules and Entra ID sign-in context.

What this kind of activity can indicate

The point is not to assume every trusted-device login is malicious. The point is to recognise when trusted access becomes a hiding place.

Infostealer malware Malware may harvest browser cookies, saved credentials and session tokens from a device that still appears compliant.

Remote access compromise An attacker may control the user's legitimate device remotely, avoiding suspicious foreign login patterns and reducing obvious identity anomalies.

Session token abuse A stolen or reused session can keep activity alive even when the user believes MFA and device compliance are protecting the account.

Data access without malware alerts The most important evidence may be file access, downloads, mailbox changes or application access rather than a malware detection.

Inherited identity trust The attacker is not always breaking in. Sometimes they are using the trusted pathway that already exists.

Misplaced confidence The environment may be configured well, but still need better visibility into behaviour after access is granted.

How GEMXIT approaches trusted-device investigations

At GEMXIT, we do not stop at the successful sign-in result. We look at identity, endpoint, cloud and behavioural evidence together.

We investigate the session SigninLogs, Conditional Access results, device details, MFA claims and token behaviour help explain why access was granted.

We correlate endpoint signals DeviceProcessEvents, DeviceNetworkEvents and Defender telemetry help determine whether the trusted endpoint behaved like a normal workstation.

We validate trust continuously The goal is practical visibility: understanding what happened before, during and after trust was granted.

Final thought

The login came through a trusted device. That was exactly why it was dangerous.

At GEMXIT We help organisations use Microsoft Defender XDR, Microsoft Sentinel, Entra ID and KQL to investigate trusted-device abuse, validate identity assumptions and improve security visibility.

Agent Foskett mindset The important question is not only: “Did the login pass?”

It is: “What happened after trust was granted?”

Continue the investigation with MFA Session Hijacking, The Session Token Never Expired, When Nothing Looks Wrong, The Dashboard Was Green, The After-Hours Download and Microsoft Security Operations.

Develop IT. Protect IT. GEMXIT PTY LTD | GEMXIT UK LTD