Agent Foskett Hub

Agent Foskett Academy — Microsoft Security Through Real Investigations A practical learning path for KQL, Microsoft Defender XDR, Sentinel and Microsoft security telemetry. Start with the basics, progress through complete identity, endpoint and cloud investigations, then move into proactive threat hunting and detection engineering.

Lesson: KQL is not just syntax — it is how investigators ask better questions of security data.

Academy Learn KQL Defender XDR

Investigation: The AI Gave The Right Answer... To The Wrong Question The analyst copied the alert into Microsoft Security Copilot.

The question was simple:

“Is this malware?”

Security Copilot found no evidence of malware. The response was accurate. The investigation was closed.

But nobody asked about the suspicious sign-in, the new inbox rule, the OAuth consent, the authentication-method change or the unusual SharePoint downloads that followed.

This Agent Foskett investigation explores Microsoft Security Copilot, AI-assisted security investigations, prompt quality, Microsoft Defender XDR, Microsoft Entra ID and why AI can give a completely correct answer while the investigation still reaches the wrong conclusion.

Lesson: AI answers the question it is given. Strong investigations depend on analysts asking the questions that reveal the complete incident.

Security Copilot AI Investigation Microsoft Defender XDR Prompt Engineering Agent Foskett

Investigation: The KQL join Revealed The Attacker The email looked harmless. The URL click appeared unrelated. The endpoint showed no obvious malware. The sign-in looked legitimate.

Every Microsoft Defender XDR table told part of the story. None revealed the full attack.

Then a single KQL join connected the evidence. Email activity, URL clicks, endpoint telemetry and identity events became one complete investigation timeline.

This Agent Foskett investigation explores KQL joins, Microsoft Defender XDR, EmailEvents, UrlClickEvents, DeviceProcessEvents and how correlating data across multiple tables uncovers attack paths that individual queries can easily miss.

Lesson: the most valuable evidence is often spread across multiple tables. Great investigators don't just query data—they connect it.

KQL join Microsoft Defender XDR Threat Hunting Investigation

Guide: Start Here: Microsoft Defender KQL Threat Hunting Guide The core Agent Foskett playbook. Real KQL queries used to detect spoofed email, authentication failures, suspicious sign-ins, URL clicks and hidden activity across Microsoft Defender, Sentinel and Entra ID.

Lesson: security isn’t only about alerts — it’s about asking the right questions of your data.

KQL Threat Hunting Microsoft Defender

Guide: Microsoft Defender KQL Threat Hunting (Complete Guide) The full Agent Foskett investigation playbook. Follow real-world attack paths across Microsoft Defender using KQL — from email spoofing and DMARC failures to URL clicks, identity pivots, endpoint behaviour and cloud activity.

Lesson: the alerts don’t tell the full story — the data does. Follow the behaviour, not just the signal.

KQL Threat Hunting Microsoft Defender Investigation

Guide: KQL Threat Hunting Alerts are useful, but they are not the full investigation.

This Agent Foskett briefing introduces practical KQL threat hunting across Microsoft Defender, Sentinel and Entra ID, showing how simple queries can uncover suspicious sign-ins, email activity, endpoint behaviour and patterns that dashboards may not explain.

Lesson: KQL helps security teams move from waiting for alerts to actively asking better questions of their data.

KQL Threat Hunting Microsoft Security

Guide: Microsoft Defender Email Security KQL Queries The email looked real, but the domains did not line up.

This Agent Foskett investigation uses KQL, EmailEvents and AuthenticationDetails to detect spoofed sender domains, DMARC failures, sender mismatch and suspicious delivery outcomes inside Microsoft Defender.

Lesson: email spoofing is often visible in the data before it is obvious to the user. The trick is knowing which fields to compare.

EmailEvents KQL Email Spoofing

Investigation: The Email Passed SPF, DKIM and DMARC — Why Did Composite Authentication Still Fail? SPF passed. DKIM passed. DMARC passed.

Everything looked legitimate. Then Microsoft Defender reported a Composite Authentication failure.

This Agent Foskett investigation explores Composite Authentication, EmailAuthenticationResults, AuthenticationDetails, email trust decisions and why passing traditional authentication checks does not always mean an email should be trusted.

Lesson: SPF, DKIM and DMARC validate technical controls. Composite Authentication evaluates whether the message deserves trust.

Composite Authentication Email Security Microsoft Defender XDR EmailEvents KQL

Investigation: The SPF Check Passed For The Wrong Domain Microsoft Defender reported:

SPF = Pass.

Everyone assumed the sender was legitimate.

But SPF had authenticated the envelope sender domain—not the visible From domain the user actually trusted.

The visible sender appeared familiar. The sending domain was authorised. The two identities were not the same.

This Agent Foskett investigation explores SPF alignment, SenderFromAddress, SenderMailFromAddress, AuthenticationDetails, EmailEvents, email authentication and how Microsoft Defender XDR helps investigators identify messages that pass SPF for a domain the recipient never expected.

Lesson: SPF can pass exactly as designed while the visible sender remains misleading. Always ask which domain was authenticated—and whether it aligns with the identity the user saw.

SPF SenderFromAddress SenderMailFromAddress EmailEvents Microsoft Defender XDR

Investigation: The DMARC Failure Was The First Clue The email looked convincing. The sender appeared legitimate. The branding was perfect.

Nobody questioned the message.

Then Microsoft Defender recorded one small detail.

DMARC = Fail.

This Agent Foskett investigation explores DMARC failures, SPF, DKIM, EmailAuthenticationResults, AuthenticationDetails, sender validation, email spoofing and how a single authentication result can become the starting point for a complete Microsoft Defender XDR investigation.

Lesson: a DMARC failure is rarely the conclusion. It is often the first clue that the sender is not who they claim to be, leading investigators toward spoofing, impersonation and authentication anomalies.

DMARC EmailAuthenticationResults AuthenticationDetails Email Security Microsoft Defender XDR

Investigation: The Reply-To Address Told The Real Story The email promised €520,000. The sender looked unusual. The wording felt suspicious.

But the real clue wasn't the prize.

It was the Reply-To address.

This Agent Foskett investigation explores Reply-To, From addresses, email headers, sender impersonation, social engineering, Microsoft Defender XDR and how a single header field can expose the true destination attackers want victims to contact.

Lesson: users often trust the visible sender, but investigators compare every email identity. Sometimes the Reply-To address reveals the attack long before anyone clicks a link.

Reply-To Email Headers Email Security Microsoft Defender XDR KQL

Investigation: The $3.2 Billion Investor Who Also Had 800 KG of Gold The email offered an extraordinary investment opportunity.

USD $3.2 billion.

But apparently that wasn't enough.

There were also 800 kg of 24-carat gold bars available for anyone who might be interested.

The supposed CFO represented one company, but the email came from a completely different domain.

Then came the request for a WhatsApp video call, KYC, due diligence and identity verification.

This Agent Foskett investigation explores investment scams, suspicious sender domains, social engineering, EmailEvents, EmailUrlInfo, Microsoft Defender XDR, KQL and how defenders can pivot from an extraordinary claim into the telemetry behind the message.

Lesson: big numbers don't equal credibility. Don't investigate the promise — investigate the person making it.

Investment Scam Email Security Social Engineering EmailEvents Microsoft Defender XDR KQL

Investigation: The Script Ran From AppData The filename did not look dangerous. PowerShell did not raise an obvious alarm. The user did not notice anything unusual.

But the script ran from AppData.

This Agent Foskett investigation explores suspicious script execution, user-writable folders, PowerShell activity, parent-child process relationships, DeviceProcessEvents, DeviceFileEvents, DeviceRegistryEvents and how Microsoft Defender XDR helps investigators follow behaviour rather than trust a filename.

Lesson: AppData is not automatically malicious, but scripts running from user-writable folders deserve context. Investigate the process tree, the file writes and what happened next.

AppData PowerShell DeviceProcessEvents Microsoft Defender XDR KQL

Investigation: The Scheduled Task Looked Legitimate — Until We Checked What It Launched The scheduled task had an ordinary name.

It ran at a predictable time.

Nothing about the task name immediately looked malicious.

Then Agent Foskett stopped looking at the name and followed what the task actually launched.

A trusted Windows component.
PowerShell.
A script inside a user-writable location.

The scheduled task wasn't the conclusion. It was the beginning of the timeline.

This investigation uses DeviceProcessEvents, DeviceFileEvents and DeviceRegistryEvents to trace scheduled-task creation, process execution, PowerShell activity and persistence evidence in Microsoft Defender XDR.

Lesson: don't investigate the name of the persistence mechanism. Investigate its behaviour.

Scheduled Tasks Persistence DeviceProcessEvents DeviceFileEvents DeviceRegistryEvents Microsoft Defender XDR KQL

Investigation: The Defender Alert Named One Device — The Evidence Found Six Microsoft Defender XDR raised an alert.

One device.
One detection.
One obvious place to investigate.

But Agent Foskett didn't stop at the alerted endpoint.

He extracted the evidence from the detection and started hunting.

File hashes. Command-line behaviour. Accounts. URLs. Network destinations.

The alert named one device. The evidence found six.

This Agent Foskett investigation uses DeviceProcessEvents, DeviceFileEvents, DeviceNetworkEvents and KQL to expand a Microsoft Defender XDR investigation beyond the endpoint where the original alert fired.

Lesson: never confuse the scope of the alert with the scope of the incident. Start with the detection. Then hunt for the scope.

Microsoft Defender XDR Advanced Hunting DeviceProcessEvents DeviceFileEvents DeviceNetworkEvents KQL

Investigation: The Antivirus Scan Was Clean — The Process Tree Wasn't The antivirus scan completed successfully.

No malware was detected. No malicious file was quarantined. The endpoint appeared clean.

But the browser had launched a Windows utility.

That process launched another process. Then came an outbound network connection.

The scan was clean. The behaviour wasn't.

Agent Foskett followed the process tree.

This Agent Foskett investigation explores Microsoft Defender XDR, DeviceProcessEvents, DeviceNetworkEvents, parent-child process relationships, command-line analysis, living-off-the-land activity and KQL techniques for investigating suspicious endpoint behaviour when antivirus detects nothing.

Lesson: no malware detection does not mean no malicious behaviour. Follow the process tree, command line, network activity and timeline.

Microsoft Defender XDR DeviceProcessEvents Process Trees Endpoint Security KQL

Investigation: The File Was Renamed Three Times Before It Executed The executable looked ordinary.

The filename did not immediately explain why it had appeared on the device.

Then Microsoft Defender XDR revealed something unusual.

Before execution, the same file had appeared under several different names.

The names changed. The hash did not.

This Agent Foskett investigation explores DeviceFileEvents, DeviceProcessEvents, SHA1 correlation, file rename activity, initiating processes, execution timelines and how Microsoft Defender XDR can reconstruct the history of a suspicious file even when its filename keeps changing.

Lesson: filenames are labels, not identity. When a suspicious file changes its name, follow the hash, the file events and the process timeline instead.

DeviceFileEvents DeviceProcessEvents File Renaming Microsoft Defender XDR KQL

Investigation: The Scheduled Task Was Created At 2:41AM The malware was gone. The alerts had stopped. Everything appeared normal.

Then, at exactly 2:41AM, Windows created a new Scheduled Task.

That single event quietly restored the attack every time the device restarted.

This Agent Foskett investigation explores Windows Scheduled Tasks, persistence techniques, schtasks.exe, DeviceProcessEvents, DeviceRegistryEvents, DeviceEvents and how Microsoft Defender XDR helps investigators uncover attacker persistence hidden inside legitimate Windows automation.

Lesson: removing malware is only part of the investigation. If persistence remains, the attacker simply comes back after the next reboot.

Scheduled Tasks Persistence Microsoft Defender XDR DeviceProcessEvents KQL

Investigation: The Scheduled Task Was The Persistence The malware disappeared after the reboot. The alerts stopped. Everything appeared normal.

Then, at exactly 8:00 AM, PowerShell launched again.

Microsoft Defender XDR revealed a scheduled task silently re-establishing attacker access every morning. This Agent Foskett investigation explores Windows Scheduled Tasks, persistence techniques, DeviceEvents, DeviceProcessEvents, DeviceRegistryEvents and how investigators uncover malicious automation hidden inside legitimate Windows task scheduling.

Lesson: removing malware is only part of the investigation. Until persistence is identified and removed, the attacker may simply come back after every reboot.

Scheduled Tasks Persistence Microsoft Defender XDR DeviceProcessEvents KQL

Investigation: The Scheduled Task Looked Legitimate — Until We Checked Who Created It The scheduled task looked completely ordinary.

The name looked legitimate. The executable looked legitimate. It even ran as SYSTEM.

Nothing immediately screamed attacker persistence.

Then Agent Foskett asked a different question:

Who actually created it?

The answer changed the investigation.

This Agent Foskett investigation follows scheduled task creation, creator identity, schtasks.exe, parent processes, account context and Microsoft Defender XDR telemetry to uncover suspicious activity hiding behind legitimate-looking Windows automation.

Lesson: the account a scheduled task runs as does not necessarily tell you who created it. Execution identity is not creator identity.

Scheduled Tasks Persistence Microsoft Defender XDR DeviceProcessEvents KQL

Investigation: The Administrator Fixed the Problem — And Deleted the Evidence The administrator saw the suspicious process.

They acted immediately.

The process was stopped. The malicious file was deleted. The machine was cleaned up.

Problem solved.

Except the SOC had not finished investigating.

By the time Agent Foskett arrived, some of the original evidence was already gone.

The question was no longer simply:

“Is the device clean?”

It became:

“What happened before the cleanup?”

This Agent Foskett investigation follows DeviceProcessEvents, DeviceFileEvents, process history, administrator activity and the remediation timeline to reconstruct what happened before the scene changed.

Lesson: containment and investigation are related, but they are not the same thing. Contain the threat without destroying the story.

Incident Response Microsoft Defender XDR DeviceProcessEvents DeviceFileEvents Evidence Preservation KQL

Investigation: Nothing Flagged The PowerShell Download No malware alert appeared. No Defender incident was raised. Everything looked normal.

Then Microsoft Defender XDR revealed that PowerShell had quietly downloaded a file from the Internet.

This Agent Foskett investigation explores suspicious PowerShell downloads, Invoke-WebRequest, DownloadString, DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents and how defenders investigate living-off-the-land activity by following behaviour instead of relying on alerts.

Lesson: the absence of an alert does not mean nothing happened. PowerShell is a trusted Windows tool, making command lines, network connections and process relationships critical parts of every investigation.

PowerShell Living Off The Land Microsoft Defender XDR DeviceProcessEvents KQL

Investigation: The PowerShell Command Never Contained a URL The analyst searched the PowerShell command line.

No http. No https. No obvious download URL.

It looked like PowerShell had never contacted the Internet.

But the network telemetry told a different story.

This Agent Foskett investigation explores DeviceProcessEvents, DeviceNetworkEvents, PowerShell execution, process correlation, network connections and how KQL can uncover activity that was never visible in the original command line.

Lesson: the command line tells you what the process was asked to do. Network telemetry helps reveal what the process actually connected to. Never stop an investigation because a URL wasn't visible in the command.

PowerShell DeviceProcessEvents DeviceNetworkEvents Microsoft Defender XDR KQL

Investigation: Mshta.exe Wasn't The Real Problem Microsoft Defender XDR raised an alert for mshta.exe. The binary looked suspicious.

But the investigation showed the executable was only one step in a much larger attack chain. The real evidence came from the parent process, the child processes and the timeline that connected them.

This Agent Foskett investigation explores Living Off The Land binaries (LOLBins), DeviceProcessEvents, parent-child process relationships, PowerShell execution, DeviceNetworkEvents and how defenders use KQL to reconstruct the complete attack path.

Lesson: don't stop at the alert. The process name starts the investigation—the process tree tells the story.

Mshta.exe LOLBins DeviceProcessEvents Microsoft Defender XDR KQL

Investigation: The USB Drive Was Never Meant To Be Found It was lying in the staff car park. Nobody knew who it belonged to. Curiosity did the rest.

Nothing obvious happened when the USB drive was inserted. Windows stayed quiet. No alerts appeared.

Minutes later, PowerShell started. A scheduled task appeared. The investigation had only just begun.

This Agent Foskett investigation explores removable media attacks, DeviceEvents, DeviceProcessEvents, DeviceRegistryEvents, persistence, scheduled tasks, PowerShell activity and how Microsoft Defender XDR helps investigators reconstruct everything that happened after an unknown USB device was connected.

Lesson: attackers often rely on curiosity rather than exploits. The USB drive is rarely the real evidence—the timeline that follows reveals the compromise.

USB Security DeviceEvents PowerShell Microsoft Defender XDR KQL

Investigation: The Recipient Was Unrecognised The email looked professional. Microsoft branding appeared genuine. A payment receipt for USD $403.22 demanded immediate attention.

The message claimed a package plan had been purchased, an order had been processed and payment had already been taken.

Everything was designed to trigger panic.

This Agent Foskett investigation explores fake payment receipts, undeliverable email scams, Microsoft impersonation, social engineering tactics and how attackers exploit urgency to convince users to call fraudulent support numbers or interact with malicious links.

Lesson: phishing campaigns do not always rely on malware. Often the attack succeeds because the user is convinced something has already happened and reacts before verifying the details.

Email Security Phishing Social Engineering Microsoft 365 Agent Foskett

Investigation: The Email Came From Zoho... But Claimed To Be Amazon The invoice looked genuine. The Zoho branding was genuine. The sending platform was genuine.

Then the message claimed an Amazon Gift Card payment had already been processed and provided a phone number for "refund enquiries."

This Agent Foskett investigation explores invoice platform abuse, refund scams, trusted SaaS services, EmailEvents, AuthenticationDetails, social engineering and why legitimate email infrastructure can still deliver malicious messages.

Lesson: trust the platform, but verify the message. Passing authentication checks does not automatically make an email trustworthy.

Email Security Zoho Invoice Refund Scam Microsoft Defender XDR KQL

Investigation: The User Reported The Email — But It Was Already Gone The user forwarded a suspicious email to the security team.

By the time investigators looked for it, the message had disappeared.

No inbox. No deleted items. No obvious evidence.

Yet Microsoft Defender already knew exactly what had happened.

This Agent Foskett investigation explores DeliveryAction, DeliveryLocation, ThreatTypes, Zero-hour Auto Purge (ZAP), quarantine actions and how defenders can reconstruct the lifecycle of a malicious email even after the message has been removed.

Lesson: the email may be gone, but the telemetry remains. Delivery actions, quarantine events and message traces often reveal more than the original message ever could.

Email Security DeliveryAction DeliveryLocation Microsoft Defender XDR KQL

Investigation: The Link Said USPS — The URL Told A Different Story The email looked genuine. USPS branding appeared convincing. The tracking message created urgency.

But one detail changed everything.

The visible link said USPS. The destination pointed somewhere completely different.

This Agent Foskett investigation explores phishing emails, deceptive hyperlinks, EmailUrlInfo, UrlClickEvents, sender impersonation, Microsoft Defender XDR and how attackers reuse legitimate HTML templates to hide malicious links inside convincing emails.

Lesson: never trust the text you can see. Investigators compare the displayed link with the actual destination because a single URL mismatch can expose an entire phishing campaign.

Email Security EmailUrlInfo UrlClickEvents Microsoft Defender XDR Phishing

Investigation: The Email Was Delivered — But Nobody Ever Saw It The message was marked as delivered.

But the user insisted it never appeared in the inbox.

No obvious alert. No visible message. No simple answer.

This Agent Foskett investigation explores DeliveryAction, DeliveryLocation, mailbox placement, quarantine outcomes, junk email routing and why delivered does not always mean the user actually saw the message.

Lesson: delivery is not the end of the investigation. Analysts need to confirm where the message landed, whether it was moved, and whether user visibility matched the telemetry.

Email Security DeliveryLocation DeliveryAction Microsoft Defender XDR KQL

Investigation: The Domain Was Blocked... The Email Still Arrived The sender had already been blocked. The domain was listed in the organisation's anti-spam policy.

Then another message appeared.

Everyone assumed Microsoft 365 had ignored the block.

Until the Internet headers revealed the truth.

This Agent Foskett investigation explores Exchange Online Protection, Internet headers, High Confidence Spam, Junk Email delivery, anti-spam policies, Microsoft Defender for Office 365 and why blocked senders do not always disappear completely from user mailboxes.

Lesson: don't assume a blocked sender bypassed your protection. Exchange Online often records exactly how the message was classified, filtered and ultimately delivered.

Exchange Online Email Security Internet Headers High Confidence Spam Microsoft Defender XDR

Investigation: The Bounce Was The First Clue A delivery failure arrived without warning. The remote mail server claimed an email had been sent from the organisation.

But nobody had sent it.

The Internet headers revealed an automated SMTP bounce, a forged sender address and a classic backscatter spam campaign.

This Agent Foskett investigation explores SMTP delivery failures, Mailer-Daemon messages, Exim mail servers, forged sender addresses, backscatter spam and how email headers reveal emails that were never actually sent.

Lesson: a genuine bounce message does not prove you sent the original email. Sometimes the only thing that was forged was your address.

Email Headers SMTP Backscatter Spam Mailer-Daemon Email Security

Investigation: The Bulk Fertilizer Order Was Only The Bait A request for bulk fertiliser arrived. The products looked legitimate. The quotation request sounded professional.

But one detail didn't fit. The sender domain didn't match the company requesting the quote.

This Agent Foskett investigation explores procurement scams, business email fraud, supplier impersonation, social engineering and how attackers use professional purchasing requests to begin conversations that can later lead to financial fraud or business email compromise.

Lesson: not every suspicious email asks you to click a link. Some simply ask you to start a conversation.

Procurement Scam Email Security Business Email Fraud Social Engineering Microsoft Defender XDR

Investigation: The Award I Didn't Enter Somehow Won Me First Prize Congratulations!

GEMXIT had apparently been selected and approved as one of Australia's best businesses.

There was only one small problem.

I couldn't remember entering anything.

This Agent Foskett investigation explores unsolicited business recognition emails, social engineering, authority and trust signals, commercial persuasion, EmailEvents, EmailUrlInfo, Microsoft Defender XDR and why an unexpected email does not have to be malicious before it deserves investigation.

Lesson: the word “Congratulations” is not an indicator of compromise. But it is an excellent reason to ask: congratulations for what, exactly?

Email Security Social Engineering EmailEvents Microsoft Defender XDR KQL

Investigation: The Sales Email Looked Suspicious — But Was It Actually Phishing? The email sounded personal.

The sender claimed they had come across GEMXIT's website and noticed an opportunity to generate more enquiries.

There was only one problem.

Nothing in the email suggested they had actually looked at the website at all.

This Agent Foskett investigation explores unsolicited sales emails, cold outreach, commercial persuasion, social engineering, EmailEvents, sender context, Microsoft Defender XDR and why a suspicious or unwanted email should not automatically be classified as phishing without evidence to support that conclusion.

Lesson: suspicious does not automatically mean malicious. Investigate the sender, the message and the intent first — then decide what the evidence actually proves.

Email Security Cold Outreach Email Investigation Social Engineering Microsoft Defender XDR

Investigation: The Defender Exclusion Was Added 12 Minutes Before the Malware Ran Microsoft Defender was running.

The device appeared protected.

Then malware executed from a location where Agent Foskett expected Defender to intervene.

So why didn't it?

Working backwards through the endpoint evidence revealed something far more interesting than the malware itself.

Just 12 minutes before execution, a Microsoft Defender exclusion had been added.

This Agent Foskett investigation explores Defender exclusions, security control tampering, DeviceRegistryEvents, DeviceProcessEvents, DeviceFileEvents, KQL and why the absence of an expected alert can become evidence of its own.

Lesson: when a security control does not behave the way you expect, don't investigate only the threat. Investigate the control as well.

Microsoft Defender XDR Endpoint Security Defender Exclusions DeviceRegistryEvents KQL

Investigation: Investigating SenderFromAddress vs SenderMailFromAddress in Microsoft Defender XDR The sender looked familiar.

The visible From address appeared trustworthy. But the envelope sender told a different story.

This Agent Foskett investigation explains how defenders compare SenderFromAddress and SenderMailFromAddress in Microsoft Defender XDR to uncover spoofing, impersonation, mismatched sender identity and suspicious email authentication behaviour.

Lesson: the address users see is not always the address used to deliver the email. Comparing visible sender and envelope sender fields can expose deception.

Email Security SenderFromAddress SenderMailFromAddress EmailEvents Microsoft Defender XDR

Guide: Using startswith and endswith in KQL Not every investigation starts with an exact match. Sometimes defenders need to find domains, file names, command lines or account values based on how the text begins or ends.

This Agent Foskett lesson explains how startswith and endswith help narrow evidence during Microsoft Defender XDR and Sentinel investigations.

Lesson: useful filtering often begins by understanding the shape of the evidence, not just the exact value.

KQL startswith endswith Threat Hunting

Investigation: The User Clicked Accept… And Gave Away The Entire Mailbox The user never typed their password into a fake website. MFA succeeded. No malware was downloaded. No endpoint alert immediately fired.

Everything looked legitimate.

But the user approved a malicious OAuth application and granted access to the mailbox through Microsoft 365 permissions. This Agent Foskett investigation explores OAuth consent phishing, malicious app permissions, offline access, mailbox visibility and why successful MFA does not always mean the session is safe.

Lesson: MFA proves the user authenticated — it does not prove the application they authorised was trustworthy. Sometimes the attacker does not steal the password. They convince the user to click Accept.

OAuth Consent Microsoft 365 Entra ID Mailbox Access KQL

Investigation: The OAuth App Asked For Permission The password was never stolen. MFA succeeded. Everything looked legitimate.

Then the user clicked Accept.

That single approval granted an application permission inside Microsoft 365. No malware was required. No password was needed.

This Agent Foskett investigation explores OAuth consent abuse, application permissions, service principals, Microsoft Entra ID and how attackers can gain access through trusted application workflows.

Lesson: MFA proves the user authenticated. It does not prove the application they authorised was trustworthy.

OAuth Consent Microsoft Entra ID Service Principals Application Permissions Microsoft 365

Investigation: The Service Principal Had Global Administrator The user account looked normal. MFA succeeded. No compromised credentials were found.

Then the permissions were reviewed.

A service principal had Global Administrator-level access.

This Agent Foskett investigation explores Microsoft Entra ID, service principals, enterprise applications, privileged permissions and how application identities can quietly become one of the most powerful attack paths inside a Microsoft 365 tenant.

Lesson: attackers do not always need a privileged user account. Sometimes the most dangerous identity in the tenant is an application nobody is monitoring.

Service Principals Microsoft Entra ID Global Administrator Enterprise Applications KQL

Investigation: The App Registration Had No Secret — So How Was It Authenticating? The application was successfully authenticating to Microsoft Entra ID.

But when Agent Foskett checked the app registration, there was no client secret.

No password-style credential.
Nothing obvious explaining the successful authentication.

Except the service principal was clearly active.

No client secret did not mean no credential.

Agent Foskett traced the workload identity, reviewed the service principal, examined its workload sign-ins and inspected the application's credentials.

The missing piece was a certificate-based key credential.

This investigation uses AADServicePrincipalSignInLogs, AuditLogs, Microsoft Graph and KQL to reconstruct how an application was authenticating without a client secret.

Lesson: when an application has no client secret, don't assume it has no credential. Identify the workload identity and determine how it actually authenticates.

Microsoft Entra ID App Registrations Service Principals Certificates Workload Identity KQL

Investigation: The Enterprise Application Had Access — Nobody Remembered Granting It The enterprise application was not new.

Its name looked familiar.
Its service principal had existed for months.

But its effective access was more powerful than anyone expected.

Microsoft Graph application permissions were assigned to it — and nobody remembered approving them.

Agent Foskett followed the service principal.

The app role assignment.
The resource service principal.
The permission ID.
The audit event.
The identity that initiated the change.

Then came the next question.

Having the permission was one thing — had the application actually used it?

Agent Foskett followed the workload sign-ins and downstream evidence to separate authorization from actual activity.

This investigation uses Microsoft Entra ID, AuditLogs, AADServicePrincipalSignInLogs, Microsoft Graph and KQL to reconstruct how an enterprise application gained powerful access.

Lesson: application permissions are privileges. Investigate what was granted, who granted it and whether it was used.

Microsoft Entra ID Enterprise Applications App Role Assignments AuditLogs AADServicePrincipalSignInLogs Microsoft Graph KQL

Investigation: One Service Principal Made 6,000 API Calls Before Breakfast There was no suspicious user sign-in.

No impossible travel.
No MFA prompt.
No interactive session.

Instead, one application identity had become extraordinarily busy.

Before most of the SOC had started work, one service principal had made more than 6,000 Microsoft Graph requests.

Agent Foskett followed the workload identity.

The service principal.
The authentication activity.
The source IPs.
The Graph endpoints.
The request methods.
The permissions.

Then the behaviour started to look different.

The volume was unusual.
The endpoints had changed.
Write operations appeared where the workload normally performed reads.

But 6,000 requests alone did not prove compromise.

Was this expected automation — or had a workload identity become the attacker?

This investigation uses Microsoft Entra ID, AADServicePrincipalSignInLogs, MicrosoftGraphActivityLogs and KQL to investigate abnormal service-principal behaviour and determine what the application actually did.

Lesson: workload identities do not need to look human to become part of an attack.

Microsoft Entra ID Service Principals Microsoft Graph Workload Identity AADServicePrincipalSignInLogs MicrosoftGraphActivityLogs KQL

Investigation: The MFA Method Was Added At 3:14AM The account had MFA enabled. The password had already been changed. Everything appeared secure.

Then the authentication methods were reviewed.

A new MFA method had been added at 3:14AM. The user was asleep.

This Agent Foskett investigation explores suspicious MFA registration, Microsoft Entra ID AuditLogs, authentication method changes, account takeover persistence and why password resets alone do not always remove attacker access.

Lesson: attackers do not always bypass MFA. Sometimes they register their own method and become part of the trusted authentication path.

MFA Registration Microsoft Entra ID AuditLogs Account Takeover KQL

Investigation: The User Didn't Reset Their Password — Someone Else Did The user's password suddenly stopped working.

They hadn't changed it.
They hadn't requested a reset.
They hadn't contacted the help desk.

But Microsoft Entra ID showed that the credential had changed.

So who changed the password?

Agent Foskett followed the Entra audit trail.

AuditLogs revealed the password operation, the affected identity and the account responsible for initiating it.

But identifying the reset wasn't enough.

What happened to the account after the password changed?

Agent Foskett pivoted into SigninLogs, identified the first authentication after the reset and reconstructed the wider identity timeline.

This investigation uses Microsoft Entra ID, AuditLogs, SigninLogs and KQL to investigate an unexpected password reset and determine who actually initiated it.

Lesson: when a user denies changing a credential, identify who initiated the operation before deciding what happened.

Microsoft Entra ID AuditLogs SigninLogs Password Reset Identity Investigation KQL

Investigation: The User Wasn't in the Group Yesterday — Today They Could Access Everything Yesterday the user could not access the application.

Today they could.

No application role had been assigned directly to the account.

No one remembered approving new access.

But one thing had changed.

The user was now a member of the group that granted it.

Agent Foskett followed the Microsoft Entra audit trail.

The membership event.
The target group.
The initiator.
The effective access.
The subsequent sign-ins.

Then came the important question:

Who added the user — and what happened after the access changed?

This investigation uses Microsoft Entra ID, AuditLogs, SigninLogs and KQL to investigate an unexpected group membership change and reconstruct the resulting access window.

Lesson: access does not always change because a permission was assigned directly. Sometimes one group membership changes everything.

Microsoft Entra ID AuditLogs Group Membership SigninLogs Identity Investigation KQL

Investigation: The Service Principal Hadn't Signed In for Months — Then It Changed a Privileged Role The service principal had been quiet for months.

No recent workload sign-ins.
No obvious reason for it to suddenly become active.

Then privileged role activity appeared in the Microsoft Entra audit trail.

A non-human identity was now part of the investigation.

Agent Foskett followed the identity evidence.

The privileged role event.
The initiator.
The target.
The service principal.
The workload sign-ins.
The source IP addresses.
The resources accessed.

But there was an important distinction to make.

Did the service principal change the role — or was it the identity receiving the privilege?

Agent Foskett separated the actor from the target and reconstructed the workload identity timeline.

This investigation uses Microsoft Entra ID, AuditLogs, AADServicePrincipalSignInLogs and KQL to investigate dormant workload identity activity around a privileged role change.

Lesson: a non-human identity can remain dormant while retaining powerful access. When it suddenly becomes active, investigate the identity — not just the operation.

Microsoft Entra ID Service Principals Workload Identities Privileged Roles AuditLogs AADServicePrincipalSignInLogs KQL

Investigation: Someone Used the Break-Glass Account — It Wasn't an Emergency The emergency access account signed in.

That should have been unusual by design.

There was no tenant lockout.
No outage requiring emergency administration.
No scheduled validation exercise.

So why had the break-glass account been used?

Agent Foskett followed the identity evidence.

The successful sign-in.
The source IP.
The application.
The target resource.
The authentication context.
The account's previous activity.

Then he followed the privileged identity into the audit trail.

What happened after the emergency account authenticated?

Agent Foskett checked directory changes, account modifications and the resources accessed after the sign-in.

This investigation uses Microsoft Entra ID, SigninLogs, AuditLogs and KQL to investigate unexpected use of an emergency access account and reconstruct the privileged activity timeline.

Lesson: emergency access should be exceptional. When a break-glass account is used outside an approved test or genuine emergency, investigate immediately.

Microsoft Entra ID Emergency Access Break-Glass Account SigninLogs AuditLogs Identity Investigation KQL

Investigation: The New MFA Method Was Registered 11 Minutes After The Login The sign-in succeeded.

Nothing about that single event proved the account had been compromised.

Then, eleven minutes later, a new authentication method was registered.

That changed the investigation.

This Agent Foskett investigation explores suspicious sign-ins, MFA registration, Microsoft Entra ID audit activity, authentication-method changes, account takeover persistence and how investigators correlate separate identity events into a single compromise timeline.

Lesson: a successful login and a new MFA method may look like separate events. Put them on the same timeline and they can tell a very different story.

MFA Registration Microsoft Entra ID Identity Investigation Account Takeover KQL

Investigation: The Global Administrator Role Was Active for Only 17 Minutes The account was checked.

It was not a Global Administrator.

Everything appeared normal.

But the audit trail showed something the current role assignment could not.

For seventeen minutes, the account had held one of the most powerful roles in Microsoft Entra ID.

This Agent Foskett investigation explores Microsoft Entra Privileged Identity Management, temporary Global Administrator activation, AuditLogs, privileged role changes, KQL and why investigators must reconstruct what permissions an identity had during the incident — not simply what permissions it has now.

Lesson: current permissions do not tell you what an identity could do during the incident. Privilege is part of the timeline.

Global Administrator Microsoft Entra ID PIM Privilege Escalation KQL

Investigation: Nobody Created the Account — Yet It Had Global Administrator The identity was sitting in Microsoft Entra ID.

It wasn't one of the recognised administrator accounts.

Yet it held one of the most powerful roles in the tenant.

Global Administrator.

The team searched for the obvious answer:

Who created the account?

But Agent Foskett had a better question:

Who gave this identity privilege?

This Agent Foskett investigation explores Microsoft Entra ID, Global Administrator, AuditLogs, RoleManagement, Privileged Identity Management, role assignments, administrative activity and KQL techniques for reconstructing how unexpected privilege appeared inside a Microsoft 365 tenant.

Lesson: privilege has provenance. When administrative access appears unexpectedly, reconstruct the role assignment, the initiator and what happened next.

Global Administrator Microsoft Entra ID AuditLogs PIM KQL

Investigation: The Security Group Was Empty — But the User Still Had Access The administrator checked the security group.

The user wasn't there.

No membership.
No obvious entitlement.
No reason they should still have access.

Except they did.

The group membership was correct. The assumption about the permission path wasn't.

Agent Foskett worked backwards from the resource, tracing direct assignments, alternate groups, supported nested-group relationships and Microsoft 365 permission evidence.

This investigation uses Microsoft Entra audit evidence, AuditLogs, OfficeActivity and KQL to reconstruct how effective access can remain even when the expected security group says otherwise.

Lesson: when the entitlement says no but the resource says yes, believe the resource — then find the path.

Microsoft Entra ID Effective Access AuditLogs OfficeActivity Permissions KQL

Investigation: The Account Wasn't an Administrator — Until PIM Activated the Role The account looked ordinary.

No permanent Global Administrator assignment.
No standing privileged role.

Nothing in the current role list explained the administrative action.

But the audit trail showed something the current-state view couldn't.

For a limited window, the account had been privileged.

Microsoft Entra Privileged Identity Management had activated the role.

Agent Foskett reconstructed the PIM activation, defined the privilege window, examined the administrative actions performed while the role was active and correlated the elevation with sign-in evidence.

This investigation uses AuditLogs, SigninLogs and KQL to investigate temporary privileged access in Microsoft Entra ID.

Lesson: a current role assignment tells you who is privileged now. An investigation must determine who was privileged then.

Microsoft Entra ID PIM Privileged Identity AuditLogs SigninLogs KQL

Investigation: The Conditional Access Result Said Success — But That Wasn't the Whole Story The sign-in succeeded.

MFA was satisfied. Conditional Access reported Success.

Everything appeared to have worked exactly as designed.

But Agent Foskett had a different question:

What exactly had succeeded?

This investigation explores Microsoft Entra Conditional Access, sign-in logs, authentication details, device context, report-only policies, session evidence and how KQL helps investigators understand what happened before and after a successful authentication.

Lesson: Conditional Access Success tells you the applicable access requirements were satisfied. It does not, by itself, prove that everything the session did afterwards was trustworthy.

Conditional Access Microsoft Entra ID Sign-in Logs Identity Investigation KQL

Investigation: The Device Was Compliant — The Session Wasn't The device was managed.

It was enrolled. It was compliant. Conditional Access allowed access.

Everything appeared trustworthy.

But the activity that followed did not match the device everyone thought they were investigating.

This Agent Foskett investigation explores Microsoft Entra ID, Conditional Access, device compliance, session context, token replay, DeviceInfo, DeviceNetworkEvents and how KQL helps investigators determine whether a trusted device really explains the activity that followed.

Lesson: a compliant device is an important security signal. It is not proof that every action associated with the session should automatically be trusted.

Device Compliance Conditional Access Microsoft Entra ID Session Security KQL

Investigation: The Login Was Successful But The Risk Was High The password was correct. MFA succeeded. The user reached Microsoft 365 without issue.

Everything looked normal.

Then Entra ID flagged the sign-in as High Risk.

The login was successful. The investigation was only beginning.

This Agent Foskett investigation explores Microsoft Entra ID Identity Protection, risky sign-ins, SigninLogs, impossible travel indicators, unfamiliar locations, Conditional Access decisions and why successful authentication does not automatically mean a session is trustworthy.

Lesson: a successful login confirms authentication. It does not guarantee the identity, device, location or session can be trusted.

Risky Sign-Ins Microsoft Entra ID Identity Protection SigninLogs KQL

Investigation: The Sign-in Was Successful... So Everyone Moved On The password was correct. MFA was approved. Conditional Access allowed the session.

Everything looked normal.

Then SharePoint downloads increased. New authentication methods appeared. Enterprise applications were granted consent. The investigation had only just begun.

This Agent Foskett investigation explores Microsoft Entra Sign-in Logs, Authentication Details, Conditional Access, Risky Sign-ins, Audit Logs and why successful authentication should mark the beginning of an investigation—not the end.

Lesson: a successful sign-in proves authentication succeeded. It does not prove the session, identity or behaviour can be trusted. Modern investigations begin with what happens after the login.

Microsoft Entra ID Sign-in Logs Conditional Access Identity Security Zero Trust

Investigation: The User Was in Melbourne — So Why Was Their Token Used in Singapore? The user was in Melbourne.

The password was correct. MFA succeeded. The authentication came from the expected device.

Then the same identity began accessing Microsoft 365 from Singapore.

The password had not necessarily been stolen.

Agent Foskett had a different question:

What if the attacker didn't need the password anymore?

This Agent Foskett investigation explores Microsoft Entra ID, session tokens, interactive and non-interactive sign-ins, IP address correlation, SigninLogs, AADNonInteractiveUserSignInLogs, Microsoft Defender XDR and KQL techniques for investigating suspected token theft.

Lesson: a legitimate sign-in does not automatically make every later session action legitimate. Follow the identity beyond the login.

Microsoft Entra ID Token Theft Session Hijacking Identity Security KQL

Investigation: The Account Behaved Normally — Compared With Everyone Except Its Peers The account did not look compromised.

It signed in successfully.
It used familiar applications.
Nothing looked obviously destructive.

Compared with the user's own recent history, very little looked unusual.

Then Agent Foskett changed the comparison.

What if the account was compared with its peers instead?

BehaviorAnalytics contained another clue.

The action was not necessarily new for the user.

But it was uncommon among the user's peers.

History said: seen before.

Peer context said: still unusual here.

Agent Foskett followed the behavioural evidence.

The UEBA event.
The ActivityInsights.
The peer relationships.
The identity context.
The underlying sign-ins.

Then came the important question.

Was the behaviour malicious — or did the user's role legitimately differ from their peers?

This investigation uses Microsoft Sentinel UEBA, BehaviorAnalytics, ActivityInsights, UserPeerAnalytics, IdentityInfo and KQL to investigate behaviour that only became suspicious when the baseline changed.

Lesson: normal behaviour depends on who — and what — you compare it with.

Microsoft Sentinel UEBA BehaviorAnalytics UserPeerAnalytics IdentityInfo Behaviour Analytics KQL

Investigation: The Impossible Travel Alert Was Wrong The alert looked serious.

A user appeared to sign in from Melbourne and then Singapore only minutes later. No commercial flight could explain the journey.

The risk score increased. The investigation suggested account compromise.

Then the device details, IP addresses and session timeline told a different story.

This Agent Foskett investigation explores Microsoft Entra ID Impossible Travel alerts, VPN exit nodes, risky sign-ins, device continuity, identity telemetry and why unusual location data does not always mean the user account was compromised.

Lesson: Impossible Travel alerts are investigation leads, not final verdicts. The alert may be real while the compromise is not.

Impossible Travel Microsoft Entra ID Risky Sign-Ins VPN Investigation KQL

Investigation: Impossible Travel Sign-In Investigation The sign-in looked impossible. One location appeared in the logs, then another location appeared shortly after.

This Agent Foskett investigation explores impossible travel sign-ins, suspicious location changes, risky authentication events and why identity telemetry must be reviewed before assuming the account is safe or compromised.

Lesson: impossible travel is not a conclusion. It is a signal that starts the identity investigation.

Impossible Travel SigninLogs Microsoft Entra ID Identity Protection

Investigation: The MFA Prompt Looked Normal The user had MFA enabled. The prompt appeared on their phone. The Microsoft sign-in flow looked familiar.

No malware alert fired. No suspicious attachment was opened. No impossible travel alert immediately explained what happened.

But the phone kept buzzing. Again and again.

Eventually, the user pressed Approve. This Agent Foskett investigation explores MFA fatigue attacks, push bombing, repeated authentication prompts, suspicious sign-in behaviour and why a normal-looking MFA prompt can still be part of an active compromise.

Lesson: MFA is essential, but users must understand that unexpected MFA prompts are security events. The prompt may be real — but the person triggering it may not be.

MFA Fatigue Push Bombing Microsoft Entra ID SigninLogs KQL

Investigation: The QR Code Was Trusted Nobody typed a password. Nobody downloaded malware. The desktop stayed clean.

The user simply scanned a QR code. The Microsoft 365 login page looked familiar. The authentication flow looked legitimate.

But the QR code redirected the user into a credential harvesting and session theft workflow designed to move the attack away from the protected corporate device and onto a trusted mobile phone.

This Agent Foskett investigation explores QR phishing attacks, mobile authentication abuse, suspicious sign-ins, token theft, Microsoft Entra ID investigations and how attackers increasingly abuse trusted mobile workflows inside Microsoft 365 environments.

Lesson: the QR code itself may look harmless — but once a trusted mobile device approves the session, the attacker may inherit legitimate access without ever deploying malware.

QR Phishing Quishing Microsoft Entra ID Session Hijacking KQL

Investigation: The User Passed MFA… But It Wasn’t Really Them The sign-in looked legitimate. The password was correct. MFA was approved. The session was trusted.

No impossible travel alert. No failed login attempts. Nothing appeared obviously malicious.

But the attacker never needed to bypass MFA. They inherited the authenticated session instead. This Agent Foskett investigation explores session hijacking, token theft, browser cookie abuse and how attackers operate inside trusted Microsoft 365 sessions after authentication has already succeeded.

Lesson: Successful MFA does not automatically prove the identity is safe. Modern attacks increasingly target session tokens, browser cookies and inherited trust, making behavioural analysis and identity investigation critical.

Microsoft Entra ID Session Hijacking Threat Hunting

Investigation: The Password Was Never Stolen — The Browser Cookie Was The user had MFA.

Their password had not been changed.

There was no obvious password spray.

Yet somebody was accessing Microsoft 365 from a network the user had never used.

The obvious assumption was: the attacker must have stolen the password.

Agent Foskett followed the session evidence instead.

The attacker may never have needed the password at all. The authenticated browser session was the real target.

This Agent Foskett investigation explores session hijacking, browser cookie theft, token replay, Microsoft Defender XDR, CloudAppEvents, IP addresses, user agents and KQL techniques for investigating suspicious Microsoft 365 session activity.

Lesson: successful authentication does not mean every action afterwards came from the person who authenticated. Sometimes the attacker doesn't steal the password — they steal the session.

Microsoft Entra ID Session Hijacking Browser Cookies Defender XDR KQL

Investigation: The Attacker Logged In After MFA The password was correct. MFA succeeded. The sign-in looked legitimate.

The security controls worked exactly as designed.

Then the attacker logged in.

The investigation revealed that authentication had succeeded, but the identity behind the session was not the person everyone expected.

This Agent Foskett investigation explores Microsoft Entra ID sign-in telemetry, successful MFA events, risky authentication patterns, session trust, identity compromise and why passing MFA does not always mean the investigation is over.

Lesson: MFA confirms an authentication event occurred. It does not automatically confirm who is operating the session afterwards.

MFA Microsoft Entra ID Identity Security Session Investigation KQL

Investigation: The Login Came Through A Trusted Device The sign-in looked legitimate. The user authenticated successfully. MFA passed. The device was compliant. Conditional Access allowed the session.

But the attacker was already inside the trusted device. This Agent Foskett investigation explores how modern attackers abuse legitimate corporate endpoints, session tokens, browser cookies and inherited trust inside Microsoft environments.

Lesson: A compliant or trusted device does not automatically mean safe activity. Modern attacks increasingly operate inside legitimate authentication flows, making behavioural analysis, endpoint telemetry and identity investigation critical.

Microsoft Entra ID Conditional Access Threat Hunting

Investigation: The User Never Shared Their Password — They Shared Their Screen “I never gave anyone my password.”

The user was absolutely certain.

No password sent in an email. No credentials entered into a suspicious website. No MFA code read over the phone.

But somebody had still been operating their computer.

Then Agent Foskett asked one more question:

“Did anybody ask you to share your screen?”

The attacker had impersonated IT support and persuaded the user to open Quick Assist, share their screen and approve remote control.

This investigation follows Quick Assist activity, endpoint processes, network connections, remote-control evidence and Microsoft Defender XDR telemetry to reconstruct what happened after the user granted access.

Lesson: an attacker does not always need the user's password. Sometimes they convince the user to give them something even more useful: control of the computer.

Quick Assist Social Engineering Remote Access Microsoft Defender XDR KQL

Investigation: The Intune Device Was Retired — But It Was Still Accessing Microsoft 365 The device had been retired in Microsoft Intune.

It was supposed to be leaving management.

Then the Microsoft Entra sign-in logs showed something awkward.

The same device was still appearing in Microsoft 365 activity after the retire action.

The obvious conclusion was that Intune had failed.

Agent Foskett followed the timestamps and found a much more important question:

When did the retire action actually reach the device?

This Agent Foskett investigation explores Microsoft Intune, Microsoft Entra sign-in logs, device identity, Conditional Access, retirement timing and how KQL can reconstruct what really happened.

Lesson: an administrative action being requested does not mean the endpoint has already processed it. Requested is not the same as completed.

Microsoft Intune Microsoft Entra ID Conditional Access SigninLogs KQL

Investigation: The Conditional Access Policy Existed... But It Wasn't Protecting Anything MFA was configured. Risk policies were configured. Device compliance checks were configured. Named locations were configured.

Everything appeared secure.

Then the Conditional Access policy was reviewed.

It was still in Report-only mode.

Sign-ins were being evaluated. The logs showed what the policy would have done. But no access decision was actually being enforced.

This Agent Foskett investigation explores Microsoft Entra Conditional Access, Report-only mode, policy assignments, exclusions, Sign-in Logs, the What If tool and why a configured security policy does not protect anything until enforcement is enabled.

Lesson: a Conditional Access policy can evaluate every sign-in and still block nothing. Configuration creates the rule—enforcement creates the protection.

Conditional Access Report-Only Mode Microsoft Entra ID SigninLogs Zero Trust

Investigation: The Inbox Rule Hid The Evidence The email was gone. No warning. No deletion alert. No sign of the message in the inbox.

But after a suspicious sign-in, a new inbox rule appeared. Messages were quietly moved out of sight before anyone knew to investigate.

This Agent Foskett investigation explores hidden mailbox rules, CloudAppEvents, EmailEvents, UrlClickEvents and KQL to uncover post-compromise activity designed to conceal suspicious email from users and defenders.

Lesson: the evidence is not always deleted. Sometimes attackers simply move it somewhere nobody is looking.

Inbox Rules CloudAppEvents EmailEvents KQL Microsoft 365

Investigation: The Inbox Rule Was Created At 2:13AM The login itself did not trigger panic. MFA succeeded. The account was not immediately disabled. No malware alert fired.

But at 2:13AM, a new inbox rule quietly appeared inside the mailbox. The rule forwarded messages externally, moved replies into hidden folders and reduced the chance the user would notice suspicious activity.

This Agent Foskett investigation explores hidden mailbox persistence, suspicious forwarding behaviour and post-authentication compromise activity across Microsoft 365 environments.

Lesson: successful authentication does not mean the investigation is over. Sometimes the real compromise begins after the login succeeds.

OfficeActivity Microsoft 365 Inbox Rules KQL

Investigation: The Dashboard Was Green No critical alerts. No active incidents. Everything appeared healthy.

But hidden inside Microsoft Defender XDR telemetry were subtle behavioural signals: unusual sign-ins, suspicious SharePoint activity, persistent sessions and authentication patterns that did not match normal business behaviour.

This Agent Foskett investigation explores why modern security teams must move beyond dashboards and learn how to ask the data better questions.

Lesson: Modern investigations rarely begin with obvious alerts. The most important signals are often buried inside normal-looking telemetry, behavioural patterns and low-severity activity that nobody questioned.

Defender XDR KQL Hunting Security Telemetry

Investigation: The Backup Was Right Next To The Fire It started with a single email.

Within hours, two servers, fifteen workstations and the on-site backups were encrypted.

Then the ransom note appeared.

The attackers believed recovery was impossible because every system they could see had already been destroyed.

This Agent Foskett investigation explores ransomware recovery, encrypted backup systems, disaster recovery planning, business continuity and the cloud backup that ultimately saved the business.

Lesson: a backup is only valuable if the attacker cannot reach it. When the fire starts, the backup should not be standing in the flames beside everything else.

Ransomware Business Continuity Azure Backup Disaster Recovery Cyber Security

Investigation: Cyber Security Is Not Just Antivirus In 2026, many organisations still believe cyber security means installing antivirus software and hoping for the best. But the threat landscape has moved far beyond traditional malware. This Agent Foskett investigation explores identity attacks, persistent sessions, spoofed domains, token theft, cloud telemetry and the hidden signals modern dashboards often miss.

Lesson: Modern attacks often target identities, sessions, cloud services and user behaviour rather than simply dropping malware onto a device. Security today is about visibility, interpretation and understanding the signals behind the events.

Microsoft Security Identity Protection Threat Hunting

Investigation: Cyber Security Has Moved Beyond Basic Antivirus Most organisations still ask the same question:

“Did antivirus detect anything?”

But modern attacks rarely look like traditional malware anymore. The dashboard may stay green while attackers operate quietly through trusted sessions, successful MFA prompts, OAuth abuse, browser token theft and suspicious cloud activity.

This Agent Foskett investigation explores why Microsoft Defender XDR, Sentinel, Entra ID telemetry and KQL threat hunting have become critical for investigating the hidden signals modern antivirus often misses.

Lesson: modern cyber security is no longer only about blocking malware — it is about understanding behaviour, identity, telemetry and the signals hidden inside trusted activity.

Microsoft Defender XDR Threat Hunting KQL Identity Security Microsoft Sentinel

Investigation: The Session Token Never Expired The user had not entered their password in months. No MFA prompt. No reauthentication. Every morning the laptop simply opened straight into Outlook, Teams and SharePoint. This investigation explores persistent Microsoft 365 sessions, refresh tokens, remembered devices and the growing security risks created when convenience quietly overrides identity controls.

Lesson: MFA does not automatically mean the session is safe. Long-lived authentication, persistent browser sessions and weak sign-in controls can quietly become one of the biggest blind spots in modern environments.

Session Security Refresh Tokens Conditional Access

Investigation: The VPN Login Continued After The Exit Meeting The employee had already been terminated. The laptop had been returned. HR believed access had been removed — but the VPN login attempts continued. This investigation explores incomplete offboarding, persistent sessions, identity gaps and the operational risks that survive after employee termination.

Lesson: Disabling an account is not always the same as removing access. Security visibility must extend across VPNs, sessions, devices, cloud apps and identity systems.

Identity Security VPN Access Offboarding

Investigation: The User Downloaded 4GB Of Data Before Resigning The user had not triggered an alert. The account was not compromised. The sign-ins looked normal.

Then the download activity was reviewed.

More than 4GB of company data had been downloaded shortly before the employee resigned.

This Agent Foskett investigation explores SharePoint and OneDrive download activity, CloudAppEvents, behavioural baselining, data exfiltration, insider risk and how Microsoft Defender XDR can reveal unusual cloud behaviour even when the identity itself appears completely legitimate.

Lesson: legitimate credentials do not automatically mean legitimate behaviour. Sometimes the identity looks normal — but the volume does not.

Insider Risk Data Exfiltration SharePoint OneDrive CloudAppEvents KQL

Investigation: The Attacker Didn't Download the Files — They Shared Them The security team searched for the download.

There wasn't one.

No 4GB transfer. No suspicious archive. No obvious mass-download event.

Yet sensitive company files had still been exposed.

The attacker hadn't taken the data.

They had changed who could access it.

This Agent Foskett investigation explores SharePoint, OneDrive, external sharing, CloudAppEvents, Microsoft Defender XDR, cloud audit activity and how KQL can uncover data exposure that never looks like traditional file exfiltration.

Lesson: data does not have to leave through a download to be exposed. Sometimes the most important event is a change in who can access it.

SharePoint OneDrive CloudAppEvents Data Exfiltration KQL

Investigation: The File Was Never Downloaded — It Was Synchronised The investigators searched for bulk downloads.

Nothing unusual appeared.

No 4GB browser download. No obvious file-transfer spike. No malware alert.

But thousands of company files had still arrived on the user's device.

The files were never downloaded one by one. OneDrive had synchronised the library.

This Agent Foskett investigation explores OneDrive and SharePoint synchronisation, CloudAppEvents, endpoint telemetry, data movement and why investigators must search for outcomes rather than only the actions they expect.

Lesson: the first query was not wrong — the investigation was too narrow. If the evidence says the files moved, keep investigating until you understand how.

OneDrive SharePoint Data Exfiltration CloudAppEvents Defender XDR KQL

Investigation: The File Was Downloaded Once — Then Appeared on 37 Devices The security team found the same suspicious file on 37 devices.

The obvious explanation?

Thirty-seven downloads.

Except the evidence showed only one.

The file had been downloaded to one endpoint and then propagated internally across the network.

Agent Foskett followed the file hash, device activity, initiating processes, network connections and SMB evidence to reconstruct how one copy became 37.

The important question was no longer:

“Who downloaded the file?”

It was:

“How did the other 36 devices get it?”

Lesson: do not count copies and assume downloads. One download can become 37 copies without 37 people clicking anything.

Microsoft Defender XDR DeviceFileEvents SMB Lateral Movement File Propagation KQL

Investigation: The User Didn't Upload the File — OneDrive Did It Automatically The file appeared in OneDrive.

The audit trail showed cloud activity.

There was only one problem.

The user insisted they had never uploaded it.

Agent Foskett followed the timeline back to the endpoint and found the missing piece.

The file had been created locally inside a synchronised folder, and OneDrive had moved it into the cloud automatically.

This Agent Foskett investigation explores OneDrive, cloud synchronisation, CloudAppEvents, DeviceFileEvents, DeviceProcessEvents, endpoint-to-cloud correlation and how KQL can distinguish a deliberate upload from an automatic synchronisation event.

Lesson: do not confuse the final cloud event with the action that caused it. The file reached OneDrive — but that does not mean the user manually uploaded it.

OneDrive CloudAppEvents DeviceFileEvents File Synchronisation KQL

Investigation: The User Shared The File With Everyone The document was supposed to be internal. The link was only meant for a few people. Everything looked normal.

Then the permissions were checked.

The file was accessible to everyone. This Agent Foskett investigation explores SharePoint sharing links, OneDrive permissions, anonymous access, external collaboration and how sensitive information can become exposed without a single attacker.

Lesson: data breaches do not always begin with malware or compromise. Sometimes the risk starts with a sharing setting nobody questioned.

SharePoint OneDrive Data Exposure

Investigation: The SharePoint Folder Was Private — Until Someone Created an Anonymous Link The SharePoint folder looked private.

The expected users had access.
The expected groups had access.

Nothing in the visible membership suggested public exposure.

But the audit trail contained another permission path.

Someone had created an anonymous sharing link.

Agent Foskett reconstructed the sharing event, identified the affected content, investigated who created the link and defined the potential exposure window.

Then came the important question:

Was the link merely created — or was the content actually accessed?

This investigation uses Microsoft 365 audit evidence, OfficeActivity and KQL to investigate anonymous SharePoint sharing and distinguish potential exposure from confirmed access.

Lesson: private membership does not guarantee private content when another sharing path exists.

SharePoint Online Anonymous Links Microsoft 365 OfficeActivity Data Exposure KQL

Investigation: The DLP Alert Looked Like a False Positive — Until We Followed the File The DLP alert looked ordinary.

A user had handled a document containing sensitive information.

The business explanation sounded plausible.

It would have been easy to classify the alert as noise and move on.

Agent Foskett did something else.

He followed the file.

The SharePoint activity.
The download.
The user.
The device.
The processes that handled the file.
The surrounding network connections.

Then the timeline started to change.

The DLP event was not the first event.

It was one point in a much longer file history.

Agent Foskett correlated Microsoft 365 audit evidence with endpoint telemetry and followed the document beyond the original alert.

Then came the real question.

Was the complete data-handling path actually authorised?

This investigation uses Microsoft Purview DLP, OfficeActivity, DeviceFileEvents, DeviceNetworkEvents and KQL to reconstruct the movement of sensitive information.

Lesson: a DLP alert tells you where to start. The file can tell you where the data actually went.

Microsoft Purview DLP Microsoft 365 OfficeActivity Defender XDR Data Exposure KQL

Investigation: The User Was Disabled… But The Account Was Still Active HR confirmed the employee had left. The Microsoft 365 account was disabled. The laptop had supposedly been returned.

But the investigation showed something uncomfortable: active sessions were still alive, authentication tokens still existed, and access continued quietly in the background.

This Agent Foskett investigation explores incomplete offboarding, persistent Microsoft 365 sessions, refresh token survival, remembered devices and why disabling an account does not always terminate access immediately.

Lesson: disabling a user account is only part of offboarding. If sessions, tokens and trusted devices are not reviewed properly, access may quietly survive long after the employee has left.

Offboarding Session Security Microsoft Entra ID Conditional Access

Investigation: The Account Was Disabled — But The Refresh Token Still Worked At 9:17 AM, the compromised account was disabled.

Everyone assumed the attacker had been locked out.

Then activity continued.

The password was no longer the important part of the investigation. A session already existed, and the evidence showed why disabling an account should never be treated as proof that containment is complete.

This Agent Foskett investigation explores Microsoft Entra ID, refresh tokens, persistent sessions, interactive and non-interactive sign-ins, session revocation, Conditional Access and how investigators verify that access has actually stopped after an account is disabled.

Lesson: disabling an account is a containment action, not proof of containment. Always verify what happened to the sessions and tokens that already existed.

Microsoft Entra ID Refresh Tokens Session Security Conditional Access KQL

Investigation: The User Was Added To A Privileged Group At 3:12AM The sign-in looked legitimate. MFA succeeded. The account already appeared trusted.

No impossible travel alert. No malware detection. No obvious compromise warning.

But at 3:12AM, the user was quietly added to a privileged Microsoft Entra ID role. Global Administrator.

This Agent Foskett investigation explores privilege escalation, suspicious role assignments, PIM abuse, overnight administrative access and how attackers quietly move from user access to tenant control inside Microsoft 365.

Lesson: modern compromise does not always begin with ransomware or malware — sometimes it begins with a privileged role assignment nobody questioned.

Microsoft Entra ID Privilege Escalation AuditLogs KQL

Investigation: The Conditional Access Policy Was In Report-Only Mode The policy existed. MFA was configured. Device compliance was evaluated. risky sign-ins were being assessed.

Everything looked like it was protected.

But the policy was still in Report-Only mode. It evaluated the sign-in, recorded the result, and showed what would have happened.

It did not block anything.

This Agent Foskett investigation explores Conditional Access policies, report-only evaluation, MFA enforcement gaps, sign-in logs and the dangerous difference between a control that exists and a control that is actually enforced.

Lesson: a security policy that only reports is not the same as a security policy that protects. Visibility is useful — but enforcement is what stops the session.

Conditional Access Report-Only Microsoft Entra ID SigninLogs

Investigation: “Misconfigurations That Passed Health Checks But Failed Reality” — The Operational Gaps Hidden Behind Healthy Dashboards Microsoft Defender was deployed. Sentinel was collecting logs. MFA was enabled. Secure Score looked healthy.

Yet during investigation, operational exposure still existed beneath apparently compliant Microsoft environments.

This Agent Foskett briefing explores how exclusions, configuration drift, incomplete telemetry and overlooked assumptions quietly survive inside environments that technically appear secure.

Lesson: dashboards may confirm configuration — but investigations reveal operational reality.

Microsoft Sentinel Microsoft Defender XDR KQL Threat Hunting

Investigation: Nothing Was Detected — Because Nobody Was Collecting the Log Suspicious activity had occurred on a server.

The SOC searched Microsoft Sentinel.

Nothing.

No matching security events. No useful timeline. No detection.

The obvious conclusion?

Nothing happened.

Agent Foskett asked a more important question:

“Were we actually collecting the evidence?”

The investigation followed Windows Security Events, SecurityEvent, WindowsEvent, collection coverage, data ingestion and Microsoft Sentinel configuration.

The detection rule had not missed the telemetry.

The telemetry had never arrived.

Lesson: an empty query does not automatically mean nothing happened. Before interpreting an empty query, prove the telemetry exists.

Microsoft Sentinel SecurityEvent WindowsEvent Data Collection Telemetry KQL

Investigation: The Sentinel Connector Was Green — But the Events Had Stopped The connector looked fine.

Configured.
Connected.
No obvious warning demanded attention.

But an analyst noticed something strange.

The newest security events were hours old.

The connector still existed.
The workspace still worked.
The queries still ran.

Only the evidence had stopped arriving.

Agent Foskett stopped looking at the connector's appearance and started measuring the data itself.

The last event time.
The last ingestion time.
The ingestion delay.
The normal event cadence.
The SentinelHealth evidence.

Then came the bigger question.

What could the SOC not see while the telemetry was missing?

The collection problem had become something larger.

A detection coverage gap.

This investigation uses Microsoft Sentinel, SentinelHealth, OfficeActivity, ingestion_time() and KQL to identify stale security telemetry, distinguish delayed ingestion from stopped collection and verify that visibility has actually returned.

Lesson: monitor data freshness as well as connector health. The security control is the continuous arrival of usable telemetry.

Microsoft Sentinel Data Connectors SentinelHealth Data Ingestion Monitoring Detection Coverage KQL

Investigation: Who Disabled the Sentinel Analytics Rule? The alerts stopped.

At first, that looked like good news.

But the source telemetry was still arriving.

The KQL still returned suspicious activity.

The attacks hadn't stopped.
The detection had.

Agent Foskett checked the Microsoft Sentinel analytics rule.

It had been disabled.

So the investigation changed direction.

When was the rule changed?
Who changed it?
Was the change approved?
And had the same identity modified anything else?

Agent Foskett followed the management trail through SentinelAudit and AzureActivity.

Then came the most important question.

What happened while the SOC was blind?

The original detection logic was run across the gap to find activity that should have generated alerts.

This investigation uses Microsoft Sentinel, SentinelAudit, AzureActivity and KQL to investigate analytics-rule changes and reconstruct the resulting detection gap.

Lesson: sometimes the attacker doesn't evade the detection. They remove the detection.

Microsoft Sentinel Analytics Rules SentinelAudit AzureActivity Detection Engineering Threat Hunting KQL

Investigation: The Hunting Query Found It — The Detection Rule Didn't The hunting query worked.

Agent Foskett searched seven days of evidence.

The suspicious activity appeared immediately.

The event matched.
The entities were there.
The evidence was clear.

There was only one problem.

The same activity should have triggered a Sentinel analytics rule.

But no alert had fired.

No incident had been created.

Agent Foskett compared more than the KQL.

The query frequency.
The lookup period.
The event timestamp.
The ingestion time.
The rule configuration.
The alert evidence.
The rule health.

Then the important distinction became clear.

Finding an event now does not prove the rule could see it then.

A historical hunt and a scheduled detection may use similar KQL.

But they do not necessarily execute under the same conditions.

This investigation uses Microsoft Sentinel, DeviceProcessEvents, SecurityAlert, SentinelHealth, ingestion_time() and KQL to investigate why hunting found activity that scheduled detection missed.

Lesson: a good hunting query is not automatically a reliable detection rule.

Microsoft Sentinel Threat Hunting Analytics Rules Detection Engineering SecurityAlert SentinelHealth KQL

Investigation: The Watchlist Said Trusted — The IP Wasn't The sign-in looked suspicious.

A privileged account.
An unusual location.
An unfamiliar source IP.

But the expected Sentinel alert never appeared.

Why?

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

Agent Foskett followed the exception.

The watchlist entry.
The SearchKey.
The business owner.
The original purpose.
The review history.

Then the assumption started to fall apart.

The trusted entry referred to an old connection that was no longer being used.

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

Agent Foskett removed the trust assumption and hunted the IP directly across the retained telemetry.

Then came the bigger question.

What happened while Sentinel was treating the IP as trusted?

This investigation uses Microsoft Sentinel, watchlists, _GetWatchlist(), SearchKey, SigninLogs and KQL to investigate stale detection exceptions and reconstruct the resulting exposure window.

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

Microsoft Sentinel Watchlists Trusted IP SigninLogs Detection Engineering KQL

Investigation: The Incident Contained Three Alerts — The Fourth Was Somewhere Else The Microsoft Sentinel incident looked complete.

Three alerts.
One user.
One device.

A tidy sequence of suspicious activity.

But Agent Foskett noticed something strange.

The raw evidence showed suspicious activity before the incident's first alert.

So where was the alert that explained it?

Agent Foskett expanded the investigation.

The incident AlertIds.
The SecurityAlert records.
The shared user.
The shared device.
The wider alert history.

Then he found it.

A fourth alert.

It involved the same investigation context.

It happened earlier.

And it was not part of the incident being investigated.

The fourth alert changed the beginning of the timeline.

Then came the important question.

Was it part of another incident — and why had the evidence been separated?

This investigation uses Microsoft Sentinel, SecurityIncident, SecurityAlert, AlertIds, SystemAlertId and KQL to hunt beyond the incident boundary and reconstruct the wider attack timeline.

Lesson: an incident is a correlation of evidence. It is not necessarily the boundary of the attack.

Microsoft Sentinel SecurityIncident SecurityAlert Alert Correlation Incident Response Threat Hunting KQL

Investigation: The Logs Arrived Two Days Late — And Rewrote the Timeline The incident timeline looked complete.

Initial access.
Execution.
Persistence.
Response.

The evidence had been documented.

Then two days later, more logs appeared.

They were not new attacker activity.

They were old events arriving late.

Agent Foskett compared two different clocks.

When did the activity occur?

And when did the evidence become available?

Using event timestamps and ingestion_time(), the delay became visible.

Some records had arrived roughly two days after the activity they described.

Then the timeline changed.

The attack had started earlier than the original evidence showed.

The late events were not added to the end of the investigation.

Agent Foskett placed them where they actually belonged.

The incident timeline was rebuilt.

The conclusions were revised.

And another investigation began.

Why had the telemetry arrived so late?

This investigation uses DeviceProcessEvents, ingestion_time(), SentinelHealth and KQL to investigate delayed telemetry and reconstruct the real attack timeline.

Lesson: the logs were late. The attack wasn't. When new evidence arrives, rebuild the timeline.

Microsoft Sentinel Timeline Analysis Late-Arriving Data DeviceProcessEvents SentinelHealth Incident Response KQL

Investigation: Every Security Alert Was Quiet — But the Threat Intelligence Wasn't The SOC dashboard was green.

No active incidents.
No urgent alerts.
No suspicious activity.

Everything appeared perfectly normal.

Then a new threat intelligence report arrived.

Several suspicious IP addresses had been linked to known malicious infrastructure.

Agent Foskett had a question.

Had anyone checked whether those addresses had already appeared in the organisation's logs?

The investigation moved beyond the alert queue.

Microsoft Sentinel.
Historical network connections.
Microsoft Entra sign-in activity.
Threat intelligence indicators.

"Interesting," Agent Foskett muttered.

"The dashboard says everything is fine."

He opened another KQL query.

"Let's see whether the evidence agrees."

Using Microsoft Sentinel and KQL, this investigation demonstrates how retrospective threat hunting can identify suspicious historical activity that existing security alerts may have missed.

Lesson: No security alerts does not mean no security threats. Correlate new threat intelligence with historical telemetry, investigate suspicious matches, and continuously improve detection coverage. The absence of an alert is not proof of safety.

Microsoft Sentinel Threat Intelligence Threat Hunting Microsoft Entra ID Network Security Historical Analysis Detection Engineering KQL

Investigation: The Email Was Genuine — The Conversation Had Been Hijacked The email looked completely legitimate.

Correct sender.
Correct subject.
Correct conversation history.

Even the invoice looked familiar.

There was just one small problem.

The bank account details had changed.

Agent Foskett began investigating the Microsoft 365 mailbox.

Had the sender's account been compromised?
Had someone accessed the email conversation?
Were suspicious inbox rules hiding messages?
And where had the payment instructions actually originated?

"Interesting," Agent Foskett muttered.

"The email is genuine. Unfortunately, so is the fraud attempt."

Using Microsoft Defender XDR, Exchange Online audit evidence, Microsoft Entra sign-in logs and KQL, this investigation follows the evidence behind a suspected business email compromise.

Lesson: A genuine email conversation does not guarantee that every message is trustworthy. Investigate suspicious payment changes, verify bank details through an independently established contact channel, and correlate mailbox activity with identity evidence before reaching a conclusion.

Microsoft 365 Business Email Compromise Microsoft Defender XDR Exchange Online Microsoft Entra ID Mailbox Investigation Invoice Fraud KQL

Investigation: The Azure Deployment Succeeded — And Quietly Opened a Security Hole The Azure deployment completed successfully.

No errors. No warnings. Everything was green.

The infrastructure team was pleased.

Unfortunately, the deployment had also introduced a Network Security Group rule allowing inbound access from the internet.

The deployment had succeeded. The security configuration hadn't.

Agent Foskett began investigating the Azure Activity Logs, deployment history, NSG rules and resource configurations.

Who made the change?
Which deployment introduced the rule?
What resources were affected?
And was anything actually exposed?

"Apparently," Agent Foskett muttered, "Azure successfully deployed exactly what we asked for."

"Unfortunately, nobody asked whether it was a good idea."

Using Azure Activity Logs, Azure Resource Graph and KQL, this investigation follows the deployment evidence to identify an overly permissive network rule and establish its potential security impact.

Lesson: A successful deployment does not guarantee a secure deployment. Review infrastructure changes, validate Network Security Group rules, enforce least privilege and use Azure Policy to help prevent unintended network exposure.

Microsoft Azure Azure Activity Logs Network Security Groups Azure Resource Graph Cloud Security Azure Policy Deployment Investigation KQL

Investigation: Who Invited the Guest Who Could Read the Finance Files? The Finance team had a question.

"Who is this person?"

An external guest account had appeared in Microsoft Entra ID.

Nothing unusual about that. Organisations invite guests all the time.

Except this guest had access to confidential Finance files.

And nobody seemed to know who had invited them.

Agent Foskett opened the audit logs.

The investigation began with a simple question.

Who created the invitation?
Who granted the permissions?
What files could the guest access?
And had any documents actually been opened?

"I don't mind visitors," Agent Foskett muttered.

"But I'd prefer they didn't have a key to the Finance department."

An invitation is not the same thing as authorisation.

Using Microsoft Entra ID, Microsoft Purview audit logs, SharePoint activity and KQL, this investigation follows the guest account, its permissions and the available access evidence.

Lesson: External collaboration requires continuous access governance. Review guest invitations, group memberships, SharePoint permissions and actual file activity. Never assume an external identity is authorised simply because it exists in your tenant.

Microsoft Entra ID B2B Guest Access SharePoint Online Microsoft Purview Audit Logs Identity Governance Data Access KQL

Investigation: The DNS Query Looked Harmless — Until We Decoded the Subdomain It started with an ordinary DNS query.

No suspicious executable.
No obvious malicious download.
No dramatic security alert.

Just a workstation resolving a hostname.

Except the hostname was unusually long.

Agent Foskett examined the DNS activity.

One query became ten.
Ten became hundreds.

Each request contained a different encoded-looking subdomain.

"That's a lot of enthusiasm for a hostname," Agent Foskett muttered.

The destination domain was consistent.
The subdomains kept changing.

And when the suspicious labels were decoded, the investigation took a very different turn.

DNS was not simply resolving hostnames. It was being used to carry information.

Using Microsoft Defender for Endpoint, Microsoft Sentinel and KQL, this investigation explores DNS tunnelling, encoded subdomains, suspicious query patterns and process-level evidence.

Lesson: ordinary network protocols can carry extraordinary threats. Investigate unusual DNS query lengths, repeated subdomain changes and suspicious process activity before dismissing traffic as routine name resolution.

Microsoft Defender XDR Microsoft Defender for Endpoint Microsoft Sentinel DNS Tunnelling Data Exfiltration DeviceNetworkEvents Threat Hunting KQL

Investigation: The Private Endpoint Was Working — So Why Was the Service Still Public? The Azure private endpoint was configured.

DNS resolved correctly.
The application connected through the private IP address.
Network connectivity tests passed.

Everything appeared secure.

Except the Azure Storage service was still accessible through its public endpoint.

Agent Foskett opened the investigation.

Was the private endpoint misconfigured?
Had public network access been disabled?
Were storage firewall rules allowing unexpected connections?
And could an attacker reach the service without using the private network?

Using Azure Activity Logs, Azure Storage diagnostic logs, Azure networking configuration and KQL, the investigation examines how a correctly functioning private endpoint can coexist with an exposed public endpoint.

Private connectivity does not automatically mean public access has been disabled.

Lesson: A private endpoint is not a public access restriction. Verify public network access settings, firewall rules, DNS resolution, private endpoint connections and effective network exposure.

Microsoft Azure Azure Private Link Private Endpoints Azure Storage Network Security Azure DNS KQL

Investigation: The AI Agent Followed Its Instructions — Unfortunately, They Came From an Attacker The AI agent was working exactly as designed.

It retrieved information.
Processed the content.
Followed the instructions.
And completed the requested task.

Everything appeared normal.

Except the instructions hadn't come from the authorised user.

Agent Foskett opened the investigation.

Where had the malicious instructions originated?
Had an attacker manipulated retrieved content?
Did the AI agent trust an untrusted data source?
And had any tools or sensitive information been exposed?

Using AI interaction logs, tool execution records, Microsoft security telemetry and KQL, the investigation explores how prompt injection can redirect an otherwise legitimate AI workflow.

An AI agent following instructions does not mean those instructions were trustworthy.

Lesson: Treat retrieved content as data, not authority. Enforce tool permissions, validate instructions, monitor agent actions and protect sensitive information from prompt-injection attacks.

AI Security Prompt Injection AI Agents Microsoft Security Copilot Tool Security Threat Investigation KQL

Investigation: The Sensitive Document Never Left SharePoint — But Its Contents Did The confidential document was still in SharePoint.

Nobody had deleted it.
No suspicious download was identified.
The original file remained exactly where it belonged.

Everything appeared secure.

Until sensitive information from the document appeared somewhere it shouldn't.

Agent Foskett opened the investigation.

Who accessed the document?
Was sensitive content copied or shared?
Did Microsoft Purview detect a policy violation?
And what evidence could establish how the information was exposed?

Using SharePoint Online, Microsoft Purview DLP, Microsoft 365 audit events, endpoint telemetry and KQL, the investigation follows the evidence behind a potential information disclosure.

A document remaining in SharePoint does not mean its contents remained private.

Lesson: Protect the information, not just the file. Review access permissions, sharing activity, DLP alerts and endpoint evidence to understand how sensitive content may have been exposed.

Microsoft Purview SharePoint Online Data Loss Prevention Microsoft 365 Audit Sensitive Information Defender XDR KQL

Investigation: The Container Was Rebuilt — But the Suspicious Behaviour Returned The security team found suspicious activity inside an Azure Kubernetes container.

They deleted the affected pod.
Kubernetes created a replacement.
The new container started successfully.

Everything appeared normal.

Until the suspicious behaviour returned.

Agent Foskett opened the investigation.

Was the container image compromised?
Was a Kubernetes Deployment recreating the workload?
Had a malicious configuration survived?
And what was causing the activity to repeat?

Using Azure Kubernetes Service, Microsoft Defender for Containers, Kubernetes audit logs, container telemetry and KQL, the investigation follows the evidence through pod recreation, workload configuration and persistent suspicious activity.

Rebuilding a container does not remove a threat that exists in the source.

Lesson: Investigate the workload, not just the affected pod. Review container images, Deployments, ReplicaSets, Kubernetes RBAC and workload identities to identify the cause before redeployment.

Azure Kubernetes Service AKS Defender for Containers Kubernetes Security Container Images Threat Persistence KQL

Investigation: The Device Was Compliant Yesterday — Today It Wasn't Even Managed Yesterday, the laptop was compliant.

Microsoft Intune reported it as managed.
Microsoft Entra ID recognised the device.
Conditional Access allowed the user to sign in.

Everything appeared normal.

Until the device disappeared from management.

Agent Foskett opened the investigation.

Had the device been retired or deleted?
Was it accidentally unenrolled?
Had somebody registered a different device?
And was Conditional Access still protecting access?

Using Microsoft Intune, Microsoft Entra ID sign-in logs, device audit events, Conditional Access evidence and KQL, the investigation reconstructs the device's management and authentication history.

Yesterday's compliance does not guarantee today's security.

Lesson: Verify device identity, management state and access decisions. A device disappearing from Intune requires investigation into enrolment, compliance, registration and Conditional Access enforcement.

Microsoft Intune Device Compliance Microsoft Entra ID Conditional Access Device Identity AuditLogs KQL

Investigation: The Managed Identity Had No Password — So How Was It Misused? The Azure workload was running normally.

The managed identity had no password.
No secret to steal.
No certificate to maintain.

Everything appeared secure.

Until the identity started accessing resources it had no business touching.

Agent Foskett opened the investigation.

Which Azure workload was using the identity?
What permissions had been assigned?
Had an Azure RBAC role been changed?
And what resources had the identity accessed?

Using Azure Activity Logs, Microsoft Entra managed identity sign-in logs, Azure RBAC evidence, storage access telemetry and KQL, the investigation follows how a legitimate workload identity can become a security risk.

Passwordless does not mean permissionless.

Lesson: Protect the workload and control the identity's permissions. Managed identities eliminate credential-management risks, but excessive access and compromised workloads can still expose resources.

Microsoft Azure Managed Identities Azure RBAC Microsoft Entra ID Azure Activity Logs Storage Security KQL

Investigation: The Teams Message Came From a Colleague — But the Link Didn't Belong There The message arrived in Microsoft Teams.

It came from a colleague.
The name was familiar.
The conversation looked normal.

There was just one problem.

The link didn't belong there.

Agent Foskett opened a new case.

Had the colleague's account been compromised?
Who clicked the suspicious link?
Did the destination attempt to steal credentials?
And had anyone authenticated afterwards?

Using Microsoft Defender XDR, Microsoft Entra ID, URL click telemetry, endpoint network activity and KQL, the investigation follows the message from delivery through to potential account compromise.

A familiar sender is not proof that a message is safe.

Lesson: Investigate the link, the sender and the subsequent activity. Trust relationships can be exploited, especially when an attacker gains access to a legitimate account.

Microsoft Teams Phishing Defender XDR Microsoft Entra ID UrlClickEvents DeviceNetworkEvents KQL

Investigation: The Certificate Was Valid — But Nobody Knew Who Was Using It The certificate was valid.

Microsoft Entra ID accepted the authentication.
The application continued accessing resources.
No password was involved.

Everything appeared legitimate.

Except nobody recognised the application.

Agent Foskett began investigating.

Who owned the service principal?
Who issued or uploaded the certificate?
What permissions had been granted?
And why was the application still authenticating?

Using Microsoft Entra ID, service principal sign-in logs, application audit events and KQL, the investigation follows the evidence behind certificate-based workload authentication.

A valid certificate proves the credential was accepted. It does not prove the activity was authorised.

Lesson: Trust the evidence, not just the certificate. Review workload identity ownership, credentials, permissions and authentication activity.

Microsoft Entra ID Service Principals Certificate Authentication Workload Identities Microsoft Graph AuditLogs KQL

Investigation: At 3:21 AM, Someone Changed the Retention Policy At exactly 3:21 AM, a Microsoft Purview retention policy was modified.

No obvious security alert.
No suspicious file download.
No immediate indication of an attack.

Just an administrative change.

Except nobody could explain why it happened.

Agent Foskett opened the Microsoft 365 audit records.

A privileged account had modified the policy.

But was the change authorised?

Had an administrator been compromised?

And could the modification affect how long important business records were retained?

Agent Foskett examined retention policy configuration, Microsoft Purview audit events, administrator sign-ins and directory activity.

A successful policy change does not prove it was an authorised policy change.

Using Microsoft Purview, Microsoft Entra ID, audit logs and KQL, this investigation demonstrates how to reconstruct an unexpected administrative change and assess its potential effect on data retention.

Lesson: administrative changes need the same scrutiny as security alerts. Verify who made the change, whether it was authorised and what actually happened to the affected records.

Microsoft Purview Retention Policies Microsoft 365 Audit Microsoft Entra ID Compliance Administrative Changes Incident Investigation KQL

Investigation: Defender Detected the Threat — But the Response Action Failed Microsoft Defender XDR detected suspicious activity on a corporate device.

An alert was generated.
An incident was created.
An automated response was initiated.

Everything appeared to be working.

Except the threat hadn't actually been contained.

Agent Foskett opened the incident timeline.

The detection was genuine.

But the response action had failed.

The device was still communicating with external infrastructure.

And the SOC dashboard hadn't made the failure immediately obvious.

Agent Foskett examined Microsoft Defender XDR alerts, Action Center records, endpoint connectivity and advanced hunting evidence.

Detecting a threat is not the same as stopping it.

Using Microsoft Defender for Endpoint, Defender XDR, DeviceProcessEvents, DeviceNetworkEvents and KQL, this investigation demonstrates why analysts must verify that response actions actually succeeded.

Lesson: an attempted response is not confirmed containment. Always verify remediation status, endpoint connectivity and post-response activity before closing an incident.

Microsoft Defender XDR Defender for Endpoint Action Center Incident Response Automated Remediation DeviceProcessEvents DeviceNetworkEvents KQL

Investigation: The AI Assistant Answered a Question Nobody Should Have Asked A Microsoft 365 Copilot response caught the attention of the security team.

The answer contained sensitive business information.

The user hadn't explicitly asked for those details.

So why had the AI assistant included them?

Agent Foskett started following the evidence.

A SharePoint document contained instructions that looked like ordinary business content.

But those instructions weren't intended for a human reader.

They were designed to influence the AI assistant processing the document.

The investigation uncovered a possible prompt injection attempt.

Document permissions, version history, SharePoint audit activity and Copilot interactions became critical evidence.

The AI assistant had treated untrusted document content as an instruction.

Using Microsoft 365 Copilot, Microsoft Purview, SharePoint audit logs and KQL, Agent Foskett examines how malicious instructions hidden inside trusted-looking content can influence an AI-generated response.

Lesson: retrieved content is evidence, not authority. Review document permissions, identify untrusted instructions and investigate how AI assistants use organisational data.

Microsoft 365 Copilot Prompt Injection AI Security SharePoint Microsoft Purview Audit Logs Document Permissions KQL

Investigation: Someone Exported the Database — But No Download Was Recorded Sensitive customer records had appeared outside the organisation.

The security team searched for evidence of a download.

No exported CSV.
No downloaded spreadsheet.
No obvious file transfer.

But the data was gone.

Agent Foskett started following a different trail.

An application identity had accessed the database.

API requests had retrieved unusually large volumes of customer information.

And the activity looked remarkably similar to legitimate application traffic.

The investigation moved beyond file downloads and into database auditing, API activity, service identities and application permissions.

Data does not need to become a file before it can leave an organisation.

Using Azure SQL auditing, application telemetry, Microsoft Entra ID, Microsoft Purview and KQL, Agent Foskett reconstructs how sensitive information could be extracted without a conventional download event.

Lesson: no download event does not mean no data exfiltration. Investigate API access, database queries and application identities alongside traditional file activity.

Azure SQL Database Auditing API Security Data Exfiltration Microsoft Entra ID Microsoft Purview Application Identity KQL

Investigation: The Password Was Correct — But Nobody Had Typed It The Microsoft Entra ID sign-in log showed success.

The account was valid.
The authentication succeeded.
The password was accepted.

There was just one problem.

The legitimate user hadn't typed their password.

Agent Foskett started following the authentication evidence.

Was this an interactive sign-in?

Had an application authenticated using stored credentials?

Was a passwordless method involved?

Or was an existing session being mistaken for a new authentication?

The sign-in result was only the beginning.

Agent Foskett examined AuthenticationDetails, sign-in types, application activity and related events.

Successful authentication did not prove who was behind the keyboard.

This investigation uses Microsoft Entra ID, SigninLogs, AADNonInteractiveUserSignInLogs, AuthenticationDetails and KQL to examine unexpected authentication activity.

Lesson: a correct password does not prove a legitimate user. Follow the authentication evidence before deciding what really happened.

Microsoft Entra ID Identity SigninLogs AuthenticationDetails Non-Interactive Sign-ins Identity Investigation KQL

Investigation: The Automation Rule Closed the Incident Before Anyone Investigated It The incident appeared in Microsoft Sentinel.

A suspicious sign-in.
A privileged account.
Enough evidence to deserve an investigation.

Minutes later, the incident was closed.

The classification looked reassuring.

False Positive.

There was only one problem.

Nobody had investigated it.

Agent Foskett followed the incident history.

The creation time.
The status change.
The classification.
The automation conditions.
The action that closed the case.

The automation rule had done exactly what it was configured to do.

But its conditions were too broad.

Then came the bigger question.

How many other incidents had been closed by the same logic?

Agent Foskett reopened the underlying evidence and reviewed the historical impact of the automation.

This investigation uses Microsoft Sentinel, SecurityIncident, SentinelAudit, automation rules and KQL to reconstruct an incident that was closed before meaningful analyst review.

Lesson: automation should accelerate investigation — not replace the evidence required to justify a security decision.

Microsoft Sentinel Automation Rules SecurityIncident SentinelAudit Incident Response SOAR KQL

Investigation: I Opened The New Defender Portal… Now What? Microsoft changed the experience. Sentinel moved into Defender. The dashboards looked empty. Widgets said “No data.” Automation rules were missing. Secure Score looked confusing.

Nothing appeared broken… but nothing made sense either.

This Agent Foskett briefing explains the new unified Microsoft Defender and Sentinel experience, why the portal looks different, what UEBA actually means, why dashboards appear empty at first, and the first things organisations should configure after onboarding.

Lesson: an empty dashboard does not mean nothing is happening — it usually means the investigation visibility has not been configured yet.

Microsoft Defender Microsoft Sentinel UEBA Threat Hunting KQL

⭐ Briefing #100: One Hundred Briefings. One Investigation Mindset. One hundred Friday Cyber Briefings. Hundreds of KQL queries. Thousands of Microsoft Defender events.

This special Agent Foskett milestone reflects on the investigation mindset developed across one hundred real-world Microsoft Defender XDR, Microsoft Sentinel and Entra ID investigations. Rather than focusing on a single attack, it explores the thinking, curiosity and evidence-driven approach behind every successful investigation.

Lesson: technology provides the telemetry, but investigators uncover the story by asking better questions and following the evidence.

100th Briefing Investigation Mindset Microsoft Defender XDR KQL Agent Foskett

Investigation: The Process Tree Told The Real Story The antivirus alert never triggered. The file looked legitimate. Signed by Microsoft. No obvious incident.

But one process launched another. Then another. Then PowerShell spawned silently in the background.

This Agent Foskett investigation follows parent and child process relationships inside Microsoft Defender XDR, using DeviceProcessEvents and KQL to uncover suspicious execution chains that dashboards may never explain.

Lesson: a single process name rarely tells the full story. The real investigation begins when you follow the parent, the child and the command line.

DeviceProcessEvents Process Tree Microsoft Defender XDR KQL Endpoint Investigation

Investigation: The File Was Never Executed — But Its DLL Was Loaded The suspicious file never appeared in the process timeline.

No process creation event.
No command line showing it launch.
No obvious execution record under its own name.

It would have been easy to conclude that the file had never run.

But Agent Foskett asked a different question.

Was the file actually an executable — or was it code loaded inside another process?

DeviceImageLoadEvents contained the missing evidence.

The DLL had been loaded by a legitimate application.

Agent Foskett identified the DLL path, preserved its hash, traced the loading process and reconstructed its process lineage.

Then he investigated what happened immediately after the module was loaded.

The file never became its own process. Its code still entered one.

This investigation uses Microsoft Defender XDR, DeviceImageLoadEvents, DeviceProcessEvents, DeviceNetworkEvents and KQL to investigate suspicious DLL loading and reconstruct the endpoint timeline.

Lesson: a file does not need its own process to become part of execution. When process telemetry is empty, investigate what was loaded inside the process.

Microsoft Defender XDR DeviceImageLoadEvents DeviceProcessEvents DLL Loading Endpoint Investigation KQL

Investigation: The Child Process Shouldn't Have Existed The alert itself wasn't unusual.

A user opened a Word document. Nobody worries when WINWORD.EXE starts.

Then Word launched PowerShell.

The parent process made sense. The child process did not.

This Agent Foskett investigation follows parent-child process relationships inside Microsoft Defender XDR using DeviceProcessEvents, ProcessCommandLine analysis and KQL to uncover suspicious execution chains hidden behind trusted applications.

Lesson: a process is only part of the story. The real investigation begins when you ask who launched it, why it appeared and whether it should have existed at all.

DeviceProcessEvents Process Analysis Microsoft Defender XDR KQL Threat Hunting

Investigation: The Timeline Told The Story The sign-in looked normal.

The data access looked normal.

The lateral movement looked normal.

The timeline changed everything.

This Agent Foskett investigation explores how Microsoft Defender XDR, IdentityLogonEvents, DeviceEvents, CloudAppEvents and KQL can reconstruct attacks by connecting events that appear unrelated in isolation.

Lesson: individual events rarely tell the full story. The timeline is where investigations become evidence.

Timeline Analysis Microsoft Defender XDR KQL Investigation Threat Hunting

Investigation: The Device Was Talking To Something It Shouldn't No malware alert. No ransomware warning. No user complaint. The endpoint looked healthy.

But one device kept reaching out to an IP address nobody recognised. Every hour. Every day.

This Agent Foskett investigation explores how Microsoft Defender XDR, DeviceNetworkEvents, DeviceProcessEvents, remote IP analysis and KQL can reveal suspicious outbound communications hidden inside normal device activity.

Lesson: endpoint investigations do not stop at process names. Network behaviour can reveal what the device was really trying to reach.

DeviceNetworkEvents DeviceProcessEvents Microsoft Defender XDR KQL Endpoint Investigation

Investigation: The Firewall Allowed HTTPS — The Destination Was the Problem The outbound connection looked normal.

TCP 443.
HTTPS.
Allowed by policy.

Nothing about the firewall decision suggested anything was wrong.

But Agent Foskett wasn't investigating whether the connection was allowed.

He was investigating where it actually went.

DeviceNetworkEvents revealed the remote destination and the process responsible for the connection.

Then DeviceProcessEvents reconstructed the execution chain.

Was the process expected?
Was the destination common?
Did other devices contact it?

The protocol was normal. The destination was not.

This investigation uses Microsoft Defender XDR, DeviceNetworkEvents, DeviceProcessEvents and KQL to investigate suspicious HTTPS traffic and reconstruct the endpoint timeline.

Lesson: a permitted connection is not necessarily a trusted connection. Follow the process, investigate the destination and build the timeline.

Microsoft Defender XDR DeviceNetworkEvents DeviceProcessEvents HTTPS Network Investigation KQL

Investigation: The Connection Happened At 1:22AM Nobody was supposed to be working.

Yet at exactly 1:22AM, a workstation connected to an IP address nobody recognised.

No alert fired. No ticket was created.

This Agent Foskett investigation explores how Microsoft Defender XDR, DeviceNetworkEvents, DeviceProcessEvents and KQL can uncover suspicious after-hours activity hidden inside normal endpoint telemetry.

Lesson: a connection may look normal during business hours. The same connection at 1:22AM can completely change the investigation.

DeviceNetworkEvents DeviceProcessEvents Microsoft Defender XDR KQL After-Hours Activity

Investigation: “The PowerShell Never Triggered An Alert” — The Activity Defender Saw But Nobody Investigated No ransomware. No critical alert. No obvious malware detection.

Just a quiet PowerShell process using encoded commands, hidden execution and suspicious outbound behaviour that blended into normal activity.

This Agent Foskett briefing explores how Microsoft Defender telemetry can reveal suspicious execution chains even when no incident is generated.

Lesson: real attacks do not always trigger alarms — sometimes they execute quietly until somebody notices the behaviour.

PowerShell Threat Hunting KQL Microsoft Defender XDR

Investigation: The PowerShell Command Was Base64 Encoded No ransomware alert. No obvious malware. No suspicious filename.

Just a PowerShell command and a long string of characters that looked meaningless.

But the command wasn't meaningless. It was encoded.

This Agent Foskett investigation explores Base64 encoded PowerShell commands, DeviceProcessEvents, ProcessCommandLine analysis, suspicious parent processes and how Microsoft Defender XDR can reveal activity hidden inside encoded execution chains.

Lesson: encoded commands are not automatically malicious — but they are often worth investigating. The real story is rarely the encoded text itself. It is what happened after the command executed.

PowerShell DeviceProcessEvents KQL Microsoft Defender XDR Threat Hunting

Investigation: The EncodedCommand Was Buried In Noise The alert wasn't critical. No ransomware was detected. No malware family was identified.

Just thousands of normal process events. Software updates. Management agents. Defender activity. Scheduled tasks.

Buried inside that operational noise was a single PowerShell EncodedCommand.

This Agent Foskett investigation explores PowerShell EncodedCommand activity, DeviceProcessEvents, ProcessCommandLine analysis, parent-child process relationships and how Microsoft Defender XDR can reveal suspicious execution hidden inside normal endpoint telemetry.

Lesson: the attacker didn't hide the command. They hid it among everything else. The telemetry existed the entire time — someone just had to keep looking.

EncodedCommand PowerShell DeviceProcessEvents Microsoft Defender XDR KQL

Investigation: The Browser Spawned PowerShell The browser was trusted. PowerShell was trusted. The user was trusted.

But the process chain was not.

Microsoft Defender XDR showed a browser process launching PowerShell, creating an execution path that deserved investigation.

This Agent Foskett investigation explores browser-spawned PowerShell, DeviceProcessEvents, parent-child process relationships, suspicious command lines, fake verification prompts and how endpoint telemetry can reveal activity hidden behind trusted applications.

Lesson: trusted applications can still create suspicious process chains. The browser was not the problem by itself. PowerShell was not the problem by itself. The relationship between them changed the investigation.

Browser Spawned PowerShell DeviceProcessEvents Process Chain Microsoft Defender XDR KQL

Investigation: The User Closed The Browser... The Process Didn't The browser disappeared. The user thought everything had finished.

But one process continued running long after the window had closed.

That single child process quietly downloaded files, contacted external systems and eventually established persistence.

This Agent Foskett investigation explores browser-based attacks, PowerShell abuse, parent-child process relationships, DeviceProcessEvents, DeviceNetworkEvents and how Microsoft Defender XDR helps investigators follow activity beyond the browser itself.

Lesson: the browser may close, but the investigation doesn't. Follow the child processes, not just the application the user can see.

Browser Security PowerShell DeviceProcessEvents Microsoft Defender XDR KQL

Investigation: Rundll32.exe Was Only Following Orders Microsoft Defender XDR raised an alert involving rundll32.exe. The binary was Microsoft signed. It was running from System32. Everything appeared legitimate.

Then the command line revealed a DLL being loaded from a user-writable folder. Suddenly the investigation was no longer about the executable — it was about who told it what to run.

This Agent Foskett investigation explores Living Off The Land binaries (LOLBins), suspicious DLL execution, parent-child process relationships, DeviceProcessEvents, DeviceNetworkEvents and how Microsoft Defender XDR helps investigators uncover malicious behaviour hidden behind trusted Windows components.

Lesson: trusted Windows binaries are not always the threat. Sometimes they are simply following the attacker's instructions.

Rundll32.exe LOLBins DeviceProcessEvents Microsoft Defender XDR KQL

Investigation: The Command Line Told A Different Story The process name looked normal. The executable was signed. The file path was expected.

Then the full command line was reviewed.

Hidden switches, encoded content and a remote download changed the entire investigation. The executable identified the tool — but the arguments revealed the intent.

This Agent Foskett investigation explores ProcessCommandLine, InitiatingProcessCommandLine, suspicious PowerShell switches, encoded commands, parent-child process relationships, DeviceProcessEvents, DeviceNetworkEvents and how Microsoft Defender XDR helps analysts uncover malicious behaviour hidden behind trusted process names.

Lesson: do not stop at the executable name. The command line often explains what the process was really instructed to do.

ProcessCommandLine PowerShell DeviceProcessEvents Microsoft Defender XDR KQL

Investigation: Rundll32 Looked Legitimate Signed Microsoft binary. Running from System32. No obvious malware alert. No user complaint.

Everything looked legitimate — until Microsoft Defender XDR telemetry showed unusual command-line arguments, suspicious DLL execution paths, strange parent process activity and unexpected outbound connections.

This Agent Foskett investigation explores how attackers abuse trusted Windows binaries like rundll32.exe, and how DeviceProcessEvents and DeviceNetworkEvents can reveal behaviour that the filename alone does not explain.

Lesson: trusted process names do not automatically mean trusted behaviour. The real question is what the process was actually doing.

Rundll32 LOLBin DeviceProcessEvents Microsoft Defender XDR KQL

Investigation: The Process Was Signed By Microsoft The file was signed. The publisher looked trusted. No malware alert fired.

Everything appeared legitimate — until Microsoft Defender XDR telemetry revealed suspicious command lines, unusual parent process activity, LOLBin behaviour and outbound network connections that did not fit normal activity.

This Agent Foskett investigation explores how attackers abuse trusted Microsoft-signed binaries and why defenders must investigate behaviour, not just signatures.

Lesson: a trusted signature does not automatically mean trusted behaviour. The real investigation begins when you ask what the process actually did.

Microsoft Defender XDR LOLBin Signed Processes DeviceProcessEvents KQL

Investigation: The CertUtil Command Downloaded Something At 2:17AM The executable was signed by Microsoft. It already existed on every workstation. No malware alert fired.

Then CertUtil.exe downloaded a file from the internet.

The binary was trusted. The behaviour was not.

This Agent Foskett investigation explores CertUtil abuse, Living-Off-The-Land Binaries (LOLBins), DeviceProcessEvents, ProcessCommandLine analysis and how Microsoft Defender XDR can uncover suspicious downloads hidden behind legitimate Windows utilities.

Lesson: trusted binaries are not automatically trustworthy. The real investigation begins when you examine the command line, the parent process and what happened next.

CertUtil LOLBin DeviceProcessEvents Microsoft Defender XDR KQL

Investigation: The Attachment Was Never Opened The email arrived quietly. The attachment passed initial checks. The user said they never opened it.

But later, Microsoft Defender XDR showed suspicious file activity, PowerShell execution, outbound connections and endpoint behaviour that pointed toward something far more serious.

This Agent Foskett investigation follows attachment telemetry, SHA256 pivots, DeviceFileEvents and post-delivery activity across Microsoft Defender XDR.

Lesson: the dangerous part is not always the attachment itself — it is what happens after the file reaches the endpoint.

Microsoft Defender XDR EmailAttachmentInfo DeviceFileEvents KQL

Investigation: The User Opened The Attachment Two Days Later The email looked harmless. It arrived on Monday morning. Nobody reported it. No alert fired.

Then on Wednesday afternoon, the attachment was opened.

This Agent Foskett investigation explores how Microsoft Defender XDR, EmailEvents, EmailAttachmentInfo, NetworkMessageId, timestamps and KQL can reveal when a suspicious attachment becomes dangerous long after the email was delivered.

Lesson: email delivery is not the end of the investigation. An attachment opened days later can turn old mailbox telemetry into a live security incident.

EmailAttachmentInfo EmailEvents NetworkMessageId KQL Microsoft Defender XDR

Investigation: The User Deleted the Email — The Attacker Already Had the Attachment The user recognised the message was suspicious.

They deleted it.

Problem solved?

Not necessarily.

The email timeline showed delivery. The attachment evidence identified the file.

Then the endpoint telemetry revealed something more important:

The attachment had already reached the device before the email disappeared from the mailbox.

Agent Foskett reconstructed what happened before deletion.

This investigation explores EmailEvents, EmailAttachmentInfo, DeviceFileEvents, DeviceProcessEvents, attachment hashes, endpoint correlation and KQL techniques for following suspicious email activity from the mailbox onto the endpoint.

Lesson: removing the message is containment. Reconstructing what happened before removal is investigation.

EmailEvents EmailAttachmentInfo DeviceFileEvents Defender XDR KQL

Investigation: UrlClickEvents The email was only part of the story. The click revealed what happened next.

This Agent Foskett briefing explains how UrlClickEvents can help defenders investigate clicked links, allowed clicks, blocked clicks, delayed user activity and post-delivery behaviour inside Microsoft Defender XDR.

Lesson: delivery tells you the message arrived. UrlClickEvents tells you whether the user interacted with it.

UrlClickEvents EmailEvents Microsoft Defender XDR KQL

Investigation: The Email Promised $5,695. The Link Told A Different Story The email claimed an inactive account contained $5,695 waiting to be claimed.

All the recipient had to do was reply and begin the ownership confirmation process.

But the sender was using Gmail. The contact method was Telegram. And hidden inside the message was a tracking link.

This Agent Foskett investigation explores advance-fee social engineering, suspicious contact channels, fake unsubscribe prompts, Google Script tracking links, recipient identifiers and why engagement can be the real prize.

Lesson: the money was bait. The tracking link revealed the real investigation — who clicked, who replied and which mailbox had a human behind it.

Social Engineering Email Tracking Phishing Telegram Investigation

Investigation: The Agreement Was Ready. The Sender Wasn't. A vendor agreement had supposedly been prepared for GEMXIT.

The email included a reference number, a compliance contact and a link to open the document.

But it wasn't coming from GEMXIT.

It was coming from halloweenville.uk.

This Agent Foskett investigation explores domain impersonation, redirect links, suspicious sender infrastructure and why routine business emails can be some of the most effective social engineering attacks.

Lesson: the agreement looked legitimate. The sender infrastructure told a different story.

Social Engineering Email Security Domain Analysis Phishing Investigation

Investigation: The Disney Email Wasn’t From Disney The Disney branding looked real. The layout looked polished. The message claimed a subscription update was needed.

But the sender was not Disney. The email came from an unrelated domain, used tracking infrastructure, and pushed the recipient toward suspicious external links.

This Agent Foskett investigation explores brand impersonation, sender mismatch, redirect chains and phishing analysis using Microsoft Defender XDR, EmailEvents and UrlClickEvents.

Lesson: branding is not identity. A phishing email can look perfect on the surface while the sender, authentication signals and redirect chain tell a completely different story.

Phishing Brand Impersonation EmailEvents UrlClickEvents Microsoft Defender

Investigation: The Secure File Came From A Body Contouring Clinic The email looked like Microsoft. A secure document was waiting. The GEMXIT name was used.

But the sender was not Microsoft. The sender was not GEMXIT.

This Agent Foskett investigation explores Microsoft brand impersonation, display name spoofing, secure document phishing lures, copied email threads and how sender evidence can expose the story the email body tried to hide.

Lesson: branding is not identity. The display name may look trusted, but the sender address and telemetry tell the real story.

Microsoft Impersonation Phishing Display Name Spoofing EmailEvents KQL

Investigation: The Invoice Wasn't An Email. It Was A Calendar Invite The message claimed an Avast subscription had renewed. The amount was $473 USD. The phone numbers looked urgent.

But the scam wasn't hiding in an email attachment. It wasn't a fake login page.

It arrived as a calendar invitation.

This Agent Foskett investigation explores fake subscription renewals, calendar invitation abuse, social engineering, phone-based scams and how attackers increasingly use trusted platforms like Outlook and Google Calendar to bypass traditional email suspicion.

Lesson: attackers don't always want your password. Sometimes they just want you to call the number they control. The invitation looked legitimate. The organiser told a very different story.

Calendar Scam Phishing Social Engineering Email Security Microsoft Defender

Investigation: Detect Email Spoofing in Microsoft Defender Most spoofed emails don’t trigger alerts.

This is the full detection guide using real Microsoft Defender data — EmailEvents, AuthenticationDetails, DMARC failures, spoofed domains and user click activity.

👉 Built from real-world investigations where everything looked “normal”… until it wasn’t.

Lesson: attackers don’t always break in — sometimes they just look trusted. Your job is to prove they’re not.

Email Spoofing KQL Microsoft Defender DMARC

Investigation: SpoofedDomain in EmailEvents: What It Means and How to Investigate It The sender looked trusted. The email looked legitimate. The domain appeared familiar.

But the telemetry told a different story.

This Agent Foskett investigation explores SpoofedDomain, AuthenticationDetails, DMARC failures, sender alignment and Microsoft Defender XDR EmailEvents telemetry to help defenders investigate suspicious email behaviour using KQL.

Lesson: trust is not built from what the user sees — it is built from what the telemetry proves.

SpoofedDomain EmailEvents AuthenticationDetails KQL Microsoft Defender

Investigation: The EmailAuthenticationResults Looked Fine The sender looked trusted. The email passed through the environment quietly. The inbox showed nothing suspicious.

But hidden inside Microsoft Defender XDR telemetry, EmailAuthenticationResults and AuthenticationDetails revealed a very different story.

This Agent Foskett investigation explores SPF, DKIM, DMARC, sender alignment, SpoofedDomain analysis and suspicious email authentication behaviour using KQL inside Microsoft Defender.

Lesson: successful authentication does not automatically mean trusted behaviour — the investigation starts when you compare what the user saw against what the telemetry proved.

EmailAuthenticationResults AuthenticationDetails EmailEvents KQL Microsoft Defender

Investigation: SpoofedDomain and EmailEvents in Microsoft Defender The email looked legitimate.

But the data told a different story — SpoofedDomain signals, EmailEvents, AuthenticationDetails, DMARC failures and suspicious sender alignment all pointed to something that did not add up.

👉 Built for the exact Microsoft Defender hunting questions security teams ask when spoofed email looks trusted.

Lesson: spoofed emails are not always obvious to users — but EmailEvents and AuthenticationDetails can reveal the trust signals that failed behind the scenes.

SpoofedDomain EmailEvents KQL Microsoft Defender

Investigation: “We Won $7,146,325.16…” — The Crypto Scam That Didn’t Need Your Password The email looked exciting. The reward looked real. No malware, no exploit — just a message designed to make the user act.

This Agent Foskett briefing shows how modern scams use wallet connections, approval prompts and external channels to bypass traditional security controls.

Lesson: attackers don’t always break in — sometimes they convince you to let them in.

Email Security Phishing Social Engineering Microsoft Defender

Investigation: AuthenticationDetails Explained The email passed. The system allowed it. Everything looked fine.

But the authentication didn’t align — DMARC failed, signals conflicted, and the evidence told a different story.

This investigation shows how to read SPF, DKIM, DMARC and CompAuth in Microsoft Defender using KQL.

Lesson: passed authentication doesn’t always mean trusted — interpretation is where real detection begins.

AuthenticationDetails KQL Microsoft Defender

Investigation: SenderFrom vs SenderMailFrom The email looked legitimate. The sender matched what the user expected.

But behind the scenes, the domains didn’t align — what was shown and what was processed were not the same.

This investigation explains how to detect sender mismatch using EmailEvents and why it matters for spoofing detection.

Lesson: what the user sees isn’t always what the system processed — mismatched domains are where spoofing begins.

EmailEvents Sender Mismatch Microsoft Defender

Investigation: The Sender Wasn't Really The Sender The display name looked trusted. The visible sender looked familiar. The email appeared to come from the right place.

But Microsoft Defender XDR showed something different.

SenderFromAddress, SenderMailFromAddress, ReturnPath, SpoofedDomain and AuthenticationDetails did not tell the same story.

This Agent Foskett investigation explores sender identity, envelope sender mismatch, spoofed email signals and why the visible From address is only one part of the email investigation.

Lesson: in email investigations, the sender is not always who the user sees. Compare the visible sender, envelope sender, return path and authentication results before trusting the message.

SenderFromAddress SenderMailFromAddress EmailEvents SpoofedDomain KQL

Investigation: The DMARC Failure Nobody Investigated The email was delivered. No malware alert. No quarantine action. No user complaint.

But hidden inside AuthenticationDetails was a clue most teams never investigate.

dmarc=fail

This Agent Foskett investigation explores how Microsoft Defender XDR, EmailEvents and KQL can uncover DMARC failures, suspicious sender authentication and messages that deserve deeper investigation.

Lesson: a DMARC failure is not always malicious — but it is always a clue worth investigating.

DMARC AuthenticationDetails EmailEvents KQL Microsoft Defender

Investigation: The Link Was Clicked After The Email Was Delivered The email was delivered. No malware alert. No quarantine action. No user complaint.

AuthenticationDetails showed a DMARC failure. Nobody investigated it.

Then somebody clicked the link.

This Agent Foskett investigation explores Microsoft Defender XDR, EmailEvents, NetworkMessageId, UrlClickEvents and KQL to determine what happened after the message reached the inbox.

Lesson: email delivery is not the end of the investigation — what happens after the click often tells the real story.

UrlClickEvents NetworkMessageId EmailEvents KQL Microsoft Defender

Investigation: The User Clicked The Link Three Days Later The email arrived on Monday. No alert. No incident. No reason to investigate.

It sat quietly in the inbox for three days.

Then somebody clicked the link.

This Agent Foskett investigation explores how Microsoft Defender XDR, EmailEvents, UrlClickEvents, NetworkMessageId and KQL can reveal when a delayed click turns an old email into an active security incident.

Lesson: email delivery is only the beginning. A link clicked days later can completely change the investigation timeline.

UrlClickEvents NetworkMessageId EmailEvents KQL Microsoft Defender

Investigation: DMARC Failed… But the Email Was Delivered The email looked legitimate. The sender felt familiar. No alert was triggered.

But behind the scenes, DMARC had failed — and the message was still delivered.

No block. No warning. Just a trusted email that shouldn’t have been trusted.

Lesson: a delivered email isn’t always a safe email — authentication failures still need investigation.

DMARC Email Spoofing Microsoft Defender

Investigation: The Email Passed SPF… But Was Still Malicious SPF passed. DKIM passed. DMARC passed.

The email looked legitimate. Microsoft 365 delivered it successfully. No major alert triggered.

But deeper investigation exposed suspicious reply-chain behaviour, unusual URL activity, compromised sender indicators and authentication signals that did not align with normal business behaviour.

This Agent Foskett investigation explores how malicious emails can still appear trusted inside Microsoft Defender XDR even when authentication checks technically succeed.

Lesson: successful SPF, DKIM and DMARC checks do not automatically make an email safe. Real investigations require behavioural analysis, context and understanding what the telemetry is actually saying.

SPF EmailEvents AuthenticationDetails Microsoft Defender KQL

Investigation: The After-Hours Download Nobody Questioned The login looked normal. The account was valid. MFA had already passed.

But late at night, files started moving — dozens of downloads from SharePoint that didn’t match the user, the role, or the time.

No alert triggered. Because technically… everything was allowed.

Lesson: allowed access doesn’t mean safe behaviour — context, timing and volume matter.

SharePoint Data Access Behaviour Analysis

Investigation: EmailEvents KQL Guide for Microsoft Defender A practical Agent Foskett guide to understanding EmailEvents in Microsoft Defender. Learn how to read sender fields, interpret AuthenticationDetails, analyse delivery outcomes, and move from suspicious emails to real investigation using KQL.

Lesson: EmailEvents doesn’t just show emails — it shows what actually happened.

EmailEvents KQL Microsoft Defender Email Investigation

Investigation: Detect DMARC Fail Emails in Microsoft Defender A focused Agent Foskett investigation into DMARC failures using EmailEvents and AuthenticationDetails. Learn how to find failed authentication, check delivery outcomes, and identify spoofing, misconfigured senders or suspicious email behaviour across your environment.

Lesson: DMARC fail doesn’t mean blocked — it means something doesn’t add up. Start there.

DMARC Email Security KQL Microsoft Defender

Investigation: The MFA Was Enabled… But the Attacker Still Got In A real-world Agent Foskett briefing showing how attackers can reuse authenticated sessions even when MFA is enabled, and why Microsoft 365 security needs more than just successful sign-in checks.

Lesson: MFA protects authentication — but session behaviour still needs to be monitored.

MFA Session Hijacking Microsoft 365 Security

Investigation: DMARC Failures Explained… with KQL The email looked legitimate… but DMARC told a different story. This guide breaks down real Microsoft Defender KQL queries using EmailEvents and AuthenticationDetails to uncover spoofing, sender misalignment and failed authentication signals.

Lesson: a “DMARC fail” is not always an attack — but it is always a signal worth investigating.

KQL DMARC Defender

Investigation: “Detect Email Spoofing in Microsoft 365 with KQL” A practical Agent Foskett briefing using EmailEvents, AuthenticationDetails and KQL to detect spoofed email, failed sender authentication, internal-looking messages and suspicious delivery patterns.

Lesson: if the message looks trusted but the authentication story fails, the real question is what happened next.

Email Security KQL Microsoft 365

Investigation: “The Alert Wasn’t Understood” A low-confidence Defender alert showed suspicious PowerShell activity. No action taken. But when correlated across process, network and identity logs, it revealed a coordinated chain.

Lesson: the danger isn’t always the alert — it’s failing to understand what it means.

Defender Sentinel KQL

Investigation: “The Email Came From Me” An email appeared to come from the same address it was sent to. No breach, no login, no compromise — just identity spoofing exploiting weak email trust enforcement.

Lesson: if DMARC isn’t enforced, you don’t control your identity — attackers do.

Email Security DMARC Phishing

Investigation: The Logs Already Knew No high severity alerts. No incidents. No panic. Just one successful sign-in that looked valid on paper, until Sentinel, Defender and Entra ID exposed impossible travel, token reuse and a stolen session moving quietly.

Lesson: the danger is not always the alert you missed — it is the pattern you never looked for.

KQL Sentinel Entra ID

Investigation: “The Missing Click” Everything looked configured correctly in Microsoft 365, yet phishing emails kept getting through. The issue wasn’t a sophisticated attack — it was a transport rule that existed, but was never actually enabled.

Lesson: a security control that exists but isn’t enabled is effectively no control at all.

Microsoft 365 Exchange Online Phishing

Investigation: Azure Looked Healthy… Until One VM Failed An Azure finance environment looked fine until a critical VM failed. Backup was failing silently, no restore testing had been done, no ASR existed, and RDP was still exposed to the internet.

Lesson: cloud does not automatically make systems resilient — resilience still has to be engineered.

Azure Backup Resilience

Investigation: The RDP Port Was Open… And Everyone Could See It A public-facing RDP service looked harmless until logs revealed global connection attempts and constant probing. Nothing had “happened” yet, but the internet had already noticed it.

Lesson: exposed services are discovered faster than most organisations realise.

RDP Exposure Azure Security

Investigation: The Azure VM Didn't Have a Public IP — So How Did the Attacker Reach It? The Azure VM had no public IP.

RDP was not exposed directly to the Internet.

So how did an attacker still manage to reach it?

Agent Foskett stopped looking at the perimeter and followed the source address.

The connection came from another private IP inside Azure.

A compromised workload had used an existing private network path through virtual network peering to reach the server.

This investigation follows private IP traffic, Azure network topology, lateral movement, Microsoft Defender XDR telemetry and KQL to reconstruct the path into a supposedly isolated VM.

Lesson: removing a public IP removes one attack path — it does not remove every network path. No public IP does not mean no network path.

Azure VM VNet Peering Lateral Movement Defender XDR KQL

Investigation: Public Storage. No Authentication. A storage configuration looked convenient for sharing, but public access left data exposed without meaningful control. The setting was small. The impact could have been huge.

Lesson: one misconfigured storage setting can undo a lot of good security work.

Azure Storage Public Access Data Exposure

Investigation: The Azure Resource Was Deleted — The Activity Log Still Knew Who Did It The Azure resource was there yesterday.

Today it was gone.

There was nothing left to inspect inside it.

The obvious question was:

Who deleted it?

But Agent Foskett asked another question first.

What evidence survives when the resource does not?

AzureActivity contained the management trail.

The delete operation.
The caller.
The affected resource.
The source IP context.
The correlation ID.

Agent Foskett followed the control-plane evidence backwards and forwards through the timeline.

Then he asked whether the same caller had changed anything else.

The resource was gone. The evidence wasn't.

This investigation uses Microsoft Azure, Azure Activity Log, AzureActivity and KQL to investigate resource deletion and reconstruct the control-plane timeline.

Lesson: deletion changes the environment. It does not necessarily erase the history of how the environment was changed.

Microsoft Azure Azure Activity Log AzureActivity Resource Deletion Cloud Investigation KQL

Investigation: The Administrator Fixed the Setting — But Nobody Investigated Who Changed It The risky setting had already been fixed.

An administrator found the problem.
Corrected the configuration.
Confirmed the resource was secure again.

The ticket could have been closed.

But Agent Foskett asked one more question.

Who changed the setting in the first place?

The current configuration could only show what was true now.

So Agent Foskett went backwards.

Into AzureActivity.
The original operation.
The caller.
The caller IP.
The correlation ID.

Then the investigation expanded.

What else had the same identity changed?

The surrounding administrative activity was reconstructed.

Microsoft Entra sign-ins were examined for authentication context.

Because fixing the configuration solved only half the problem.

Was the change authorised?
Accidental?
Automated?
Or had someone used a compromised administrator identity?

This investigation uses AzureActivity, Caller, CallerIpAddress, CorrelationId, SigninLogs and KQL to reconstruct the change and investigate the identity behind it.

Lesson: remediation fixes the state. Investigation explains the cause.

Microsoft Azure AzureActivity Audit Logs Configuration Change Microsoft Entra ID Attribution KQL

Investigation: Key Vault Was Still Trusting an Identity — The VM Was Already Gone The virtual machine had been deleted.

Its workload was supposed to be gone with it.

But while reviewing Azure Key Vault activity, Agent Foskett found an identity connected to the old system.

The compute resource was gone.
The identity trail was not.

Was this simply historical telemetry?

A surviving user-assigned managed identity?

Or an authorization path nobody had cleaned up?

Agent Foskett followed the Azure evidence.

The Key Vault operation.
The principal ID.
The managed identity.
The VM deletion.
The role assignment.
The remaining resource attachments.

Then came the distinction that changed the investigation.

Was the identity system-assigned — or user-assigned?

Because deleting a VM does not necessarily mean every identity associated with that workload disappears.

This investigation uses Microsoft Azure, Azure Key Vault, AZKVAuditLogs, AzureActivity, Azure Resource Graph and KQL to reconstruct the workload identity and authorization timeline.

Lesson: when a workload disappears, verify the identity lifecycle separately from the resource lifecycle.

Microsoft Azure Azure Key Vault Managed Identities AZKVAuditLogs AzureActivity Azure RBAC KQL

Investigation: “When Nothing Looks Wrong” No alerts, no outages, no angry calls — yet a quick review found a global admin without MFA, legacy auth still enabled, short audit log retention, and Conditional Access not enforcing as expected.

Lesson: most breaches don’t start with alarms, they start with assumptions.

Audit Logs Global Admin Review

Investigation: “The MFA Was On… Just Not Everywhere” MFA existed on paper, but not for legacy authentication, temporary exclusions, or forgotten service accounts. Sign-in logs showed password spray activity quietly probing the tenant.

Lesson: MFA doesn’t protect what it doesn’t cover.

Entra ID MFA Legacy Auth

Investigation: “Just This One Exception” One temporary Conditional Access exclusion was added to help a user while travelling. It was never reviewed, never removed, and quietly weakened the tenant for months.

Lesson: most security failures start with well-intentioned shortcuts, not attackers.

Conditional Access MFA Zero Trust

Investigation: Using Impossible Travel Sign-ins to Teach Real-World Security Skills A user account appeared to sign in successfully from Melbourne and then London within minutes. The login worked, but the geography told a very different story about identity risk.

Lesson: successful authentication does not always mean trusted access.

Entra ID Impossible Travel Identity Risk

Investigation: Building Security Intuition with Sentinel Workbooks Security data was already flowing into the platform, but the real patterns stayed hidden until it was visualised properly. Once the noise became visible, the risks became much easier to understand.

Lesson: people act faster on security data when they can actually see the story it is telling.

Microsoft Sentinel Workbooks Visibility

Investigation: AI Rollout… But the Guardrails Weren’t AI tools had been deployed to boost productivity, but access was too broad, governance was unclear, and no one had tested what happened when users got creative with prompts.

Lesson: AI is not set-and-forget. Unsecured AI behaves like a highly motivated internal user with broad access.

AI Security Governance Data Access

Investigation: Your Organisation Might Soon Have AI Employees AI tools are starting to act more like users — accessing data, making decisions, and interacting across systems. But without clear governance, they can expose information faster than most organisations realise.

Lesson: AI should be treated like a user — with identity, access control, and monitoring.

AI Security Governance Data Access

Investigation: Good Friday Cyber Briefing Most organisations already have the tools, but they still do not have the visibility. Azure is deployed, Microsoft 365 is in place, and logs are being collected, yet nobody is asking what the data is actually saying.

Lesson: security is not just configuration — it is interpretation.

Azure Sentinel Defender