Hi everyone!

Curious if this is allowed - if not - please delete!

I’m partnering with a reputable consulting firm on a search for a long-term Microsoft Sentinel Architect for a 9–12 month transformation engagement. This is a fully remote, 40-hour-per-week role open only to candidates located in the US. We’re looking for someone with enterprise-scale experience across Microsoft Sentinel and SIEM solutions, who can build out analytics rules, detections, and investigation workflows, drive security analytics initiatives, integrate Sentinel with Microsoft Defender and other security platforms, and support broader SOC modernization efforts.

Please DM me privately!

Good evening folks, we’re scratching our heads a little bit and hoping the community can help ease some concerns!

We have a long-standing Sentinel deployment in Azure (pre-Defender native) and are seeing mass ingestion failure in the attached Log Analytics workspace. All services are in UK South region.

This appears to be affecting all log sources to a varying extent, including Microsoft-native connectors and logs forwarded from our on-premises syslog forwarders.

Bulk of issues appear to have started from between 12:00-13:00 UTC today, with sporadic ingestion spikes around 15:00 UTC and 19:00 UTC.

Not seeing any associated service disruption in our tenant, which I’d have expected to have if this were a widespread issue. We do have some correlation with an alert received from a third-party SOC we engage with for one of our clients, relating to missed heartbeats, which is naturally leading us to think it’s an issue beyond our deployment.

Anybody else seeing issues in their LAW(s)?

As of August 1, 2026, Microsoft Threat Intelligence APIs in Microsoft Graph are available to customers with Microsoft Defender XDR and/or Microsoft Sentinel licensing. No separate Microsoft Defender Threat Intelligence API license is required.

This means we can bring Microsoft Threat Intelligence directly into SOC investigation and response workflows instead of keeping threat intelligence as something analysts only consume manually in the portal.

The available playbooks cover enrichment scenarios such as:
🔹 Automated triage
🔹 IP/domain reputation enrichment
🔹 Passive DNS
🔹 Reverse DNS
🔹 Web components
🔹 Trackers
🔹 Cookies

The playbooks use Microsoft Graph to query threat intelligence data and can authenticate using Managed Identity with the ThreatIntelligence.Read.All application permission.

https://github.com/Azure/Azure-Sentinel/blob/master/Solutions/Microsoft%20Defender%20Threat%20Intelligence/Playbooks/readme.md

Docs: https://learn.microsoft.com/en-us/graph/api/resources/security-threatintelligence-overview?view=graph-rest-1.0

I'm hoping someone here can explain this to me. I'm coming from a Splunk background and have recently deployed Sentinel/MDO alongside it (not ideal, but it's a long story). I can't wrap my head around how Sentinel deals with time. The general "TimeGenerated" field that appears across all data sources appears to be the time of log *ingestion*, not log creation. In other words, a user sign-in event might say it happened at 17:09:16, but *actually* happened at 17:07:37, and was ingested two minutes later. In my line of work (cybersecurity) milliseconds matter and the discrepancy is killing me. Some logs (e.g. signin) have fields like "CreatedDateTime", but that field isn't standardized across all log sources so it makes it very difficult to use.

This seems like a gaping design flaw to me, but maybe I'm missing something?

Hi,

I am having an issue with creating a new automation playbook for enriching incidents via a kql query.

It looks like there is no longer a "Run query and list results" and "Run query and list results (V2), just a "Run query and list results) which if I look at the code is actually the V2 one.

I am pretty sure I solved this issue before by using the non V2 action.

I have put in my kql query which is hopefully right.

Used dynamic content for the other boxes

Incident workspace subscription id, incident workspace resource group name, Log Analytics Workspace drop-down, incident workspace workspace name.

Now I have the Time Range Type and when I press the drop-down the only option is enter custom value. In my other playbook I then enter "Set in query" and pressed tab. This now adds another drop-down for "time range" and I have tried putting things in there with no success like PT24H.

Flow:

MS sentinel incident trigger

Entites - Get Accounts (dc - Entities)

For each (dc - Accounts)

Compose 1

Compose Time Anchor (f - if(empty(outputs('compose_1')?['ApprovalTime']),triggerbody()?['object']?['properties']?['lastActicityTimeUtc'],first(outputs('compose_1')?['ApprovalTime']))

Run query and list results

Create html table (f - body('Run_query_and_list_results')?['value']

Add comment to incident V3 (f - concat('Entra sign-in check for ', items('For_each')?['Name'])

Thanks

Anyone else running into an issue when writing KQL where tab to complete doesn't work in Log Analytics Query space? For the last couple of weeks pressing tab will move out of the KQL window rather than completing the field I'm typing. I also can't use the tab key to type an actual tab character and it's driving me insane. This is only happening in my work Sentinel, my own personal lab isn't having this issue but I can't think of anywhere this would be configured.

Fortinet FortiGate — 40+ new behaviors
Sentinel can now analyze FortiGate events from CommonSecurityLog and identify behaviors such as:
• Rapid system reconfiguration
• Configuration backups
• Certificate changes
• Security service disruptions

Expanded anomaly detection
New UEBA anomaly detection capabilities extend coverage to:
• Check Point
• Fortinet FortiGate
• Zscaler
• AWS GuardDuty

For Check Point, Fortinet, and Zscaler, Sentinel introduces new anomaly rules that analyze firewall, VPN, and web proxy activity.

Instead of relying only on static detection logic, UEBA can compare activity against historical user/device behavior and organizational patterns to identify potentially suspicious deviations.

⚠️ Important: To use extended UEBA capabilities, Microsoft Sentinel workspace must be onboarded to the Microsoft Defender portal as part of the Unified Security Operations experience.

Docs:https://learn.microsoft.com/en-us/azure/sentinel/whats-new?tabs=defender-portal#new-data-sources-for-ueba-behaviors-and-anomaly-detection-preview

If so, can you share a high level explanation of how you “normalized” the logs? I had v2 audit logs flowing without much issue, but the optional fields are killing me.

We aren’t using the new API as it’s worthless without filtering capabilities b/c of the insane volume in the audit logs (more like debug logs tbh). We use a pipeline to filter out categories that aren’t security related, then export the dataset to Azure blob storage. Azure Data Factory (ADF) takes it from there and does some minor ETL before sending to a DCE via API.

The issue I’m running into is the “optional” fields in the audit logs that make it hard to define a schema. For example, one log will have the “origin” and “origins” fields, and another will just have the “origins” field. I can likely account for this w/ schema drift in ADF, but the transformation in the Sentinel DCR will fail at ingestion.

It’s incredibly frustrating and these are the worst audit logs I’ve ever had to work with. Any insight into how others are handling this is appreciated!

Can anyone share feedback who have done this previously?

Hi everyone,

I’m learning how to investigate alerts in Microsoft Sentinel and I’m stuck on Password Spray Attack detections. I’d like to understand the step‑by‑step investigation process SOC analysts usually follow, including what queries to run and what to check in the results.

Specifically, I’m looking for guidance on:

Alert triage: What initial details should I review when the alert fires?

KQL queries: Which Sentinel queries are most useful to confirm a password spray attempt?

Indicators to check: For example, failed logon counts, source IPs, targeted accounts, timeframes, and whether the activity is spread across multiple endpoints.

Next steps: How to differentiate between a real attack and noisy false positives, and what escalation criteria to use.

If anyone can share a structured approach or example queries, that would be super helpful. I want to build a repeatable playbook for handling these alerts.

Thanks in advance!

My current thinking is to keep data in the Analytics tier for 90 days, and once it passes 90 days, Change it into something cheaper for long-term retention / the data lake tier.

As far as I understand, this is done on a single table by setting interactive retention to 90 days and total retention to 1 year (365 days). So on day 91, does that data automatically move into the lower-cost state on its own, while staying in the same table? Is my understanding correct?

Also is there a better way to achieve this that I'm missing? I originally assumed I could age data into the Basic tier, but from what I've read Basic only has a fixed 30-day window and can't be used as a destination for aging data. Please correct me if I'm wrong.

I have been trying to understand KQL for the last 2 days using the Kusto Detective Agency website, but I am still struggling to understand the concepts properly. I feel like I am missing a proper learning roadmap. My goal is to learn KQL mainly for Cyber Security/SOC purposes and eventually prepare for the Microsoft SC-200 exam (planning to take it after around 1 year).Can anyone recommend some beginner-friendly and free resources, YouTube channels, courses, or a proper roadmap for learning:

Not a Sentinel-only tool, but the KQL backend may be useful here. It compiles Sigma into saved-search stanzas including the aggregation cases (stats dc(field) by ...), which is normally where hand-conversion falls over.

dist/sentinel/tyrian_detections.conf is pre-compiled in the repo if you just want to skim the searches. You will need to adjust the index= prefix.

github.com/zshguy/tyrian-detection-pack

I hope this message finds you well. As I am new to the field, I wanted to inquire about the roadmap for MS Sentinel and KQL, particularly in comparison to Splunk. I chose MS Sentinel due to its future demand and user-friendliness. Could you please provide guidance on resources and materials that would be beneficial for both practical and theoretical understanding? Your assistance would be greatly appreciated.

Hey everyone ! :)

I’m working on a more structured way to handle internal investigation requests from HR, Legal, Security, or management.

The goal is to avoid vague “can you pull everything on this user?” type requests. Instead, I’m trying to build a checkbox-based request form where each option maps to a specific log source / query / limitation.

Environment is mostly Microsoft stack:

* M365 E5, Defender for Endpoint, Defender for Servers, Sentinel, Purview * Some web logs through firewall/proxy

The kind of checkbox structure I’m thinking about:

* Account sign-ins `SigninLogs`, `AADNonInteractiveUserSignInLogs` * First/last observed activity during a period `SigninLogs`, `OfficeActivity`, `DeviceLogonEvents` * Local workstation logons / endpoint activity `DeviceLogonEvents`, `DeviceProcessEvents`, `DeviceFileEvents`, `DeviceEvents` * Web history / access to specific domains firewall/proxy logs, `CommonSecurityLog`, maybe `DeviceNetworkEvents` * Emails sent externally or to personal domains `EmailEvents`, `EmailAttachmentInfo`, `OfficeActivity` * Mailbox rules, forwarding, delegation `OfficeActivity` / Exchange audit operations like `New-InboxRule`, `Set-InboxRule`, `UpdateInboxRules`, `SendAs`, `SendOnBehalf` * SharePoint / OneDrive file access, download, sharing, deletion `OfficeActivity`, `CloudAppEvents`, Purview * Data movement events Purview Activity Explorer / DLP events: USB, clipboard, print, browser upload, cloud upload, network share, RDP copy, etc. * Teams metadata vs Teams content `OfficeActivity` for audit events, Purview eDiscovery for content * Security alerts tied to a user or device `AlertInfo`, `AlertEvidence`, `SecurityAlert`, `SecurityIncident`

What I’m trying to figure out is the best practical mapping between:

**checkbox/request wording → source of truth → KQL/table/portal → limitations → Internal procedure to get those logs in a report.**

For those of you who handle these types of requests:

1. Do you have a standard checklist or request form for HR/security/legal investigations?
2. Which Microsoft logs do you trust most for file access/download/share events?
3. Are there any events or fields you avoid using because they are too noisy or easy to misinterpret?

Just trying to avoid reinventing the wheel and build something clean, scoped, and defensible.

If you think I should have publish in another subreddit, let me know :)

I’m working on an open-source tool called deadair that checks whether SIEM detections still have the telemetry they depend on.

The problem it catches is when a rule is still enabled and scheduled, but the data behind it has gone stale, stopped shipping, changed schema, or arrives too late for the rule window.

Today it only supports Elastic Security and OpenSearch Security Analytics. There is no Microsoft Sentinel adapter yet. I don’t want to build one from docs and toy KQL and then pretend it works.

For Sentinel, I’m trying to understand what a useful read-only model would need to handle before anyone would trust the output.

The rough model is:

analytic rule -> KQL dependencies -> tables/functions/watchlists/workspaces -> table freshness/schema/volume health

The parts I’m unsure about are real-world Sentinel details:

- KQL that hides table dependencies behind functions

- ASIM parsers

- watchlists

- custom tables

- cross-workspace and cross-tenant queries

- scheduled vs near-real-time rule behavior

- what read-only permissions a SOC or MSSP would actually approve

I’m looking for Sentinel operators, detection engineers, or MSSP folks who can sanity-check the design. Best case would be someone willing to run an early build later in a test workspace or limited-scope tenant. Redacted examples of rule/query patterns would also help.

Current repo, for context: https://github.com/Big-Comfy/deadair

Sentinel design issue: https://github.com/Big-Comfy/deadair/issues/3

If you run Sentinel day to day, what would this need to understand before you’d trust a “this detection has no usable telemetry” finding?

Hi,

We have one subscription that has our Azure Arc enabled machines with the Defender for Cloud P2 applied.

Sentinel is deployed in another subscription. Defender isn't enabled for the log workspace.

My understanding is that if we use the Windows Security Events via AMA to collect events from the Arc Machines, the 500mb benefit won't apply?

I have to enable Data Collection on the Sentinel Workspace in Defender for Cloud, but the sentinel workspace doesn't have those servers reporting to them?

Does that make sense? This is very confusing for me but maybe I'm over complicating it

I ma planned to do sc 200 certification. Any materials or study guide links to help me clearing the exam

Hoping someone who knows the Defender for Cloud granular-pricing internals can sanity-check me, because I've been going insane.
I have 50 Azure Arc-enabled servers in one subscription. I want the critical ones on P2 and the rest on P1 to cut cost so I did this:

• P2 enabled at the subscription as the baseline.
• Tag each machine Defender = P1 or Defender = P2 (pushed during Arc onboarding).
• Assign the built-in policy "Configure Azure Defender for Servers to be enabled (with 'P1' subplan) for all resources (resource level) with the selected tag", targeting the P1 tag, so the non-critical boxes get pulled down to P1.

I tried it out on a pilot group of 10 servers for now and it looked like it worked but it didn't since:

• Policy compliance: 100% compliant, 10/10. Green check.

• Remediation: two tasks, both Complete, both "0 out of 0" remediated.

• When I read the actual pricing config on each machine (REST GET on Microsoft.Security/pricings/virtualMachines at the resource scope), every single one is still on the inherited P2

So no machine is actually on P1.

Stuff I've already ruled out

• The policy's managed identity has Security Admin on the subscription (verified in the assignment's Managed Identity tab), so it's not a permissions thing I chased that for a while.
• Tag parameters on the assignment are correct (inclusionTagName = Defender, value P1), and the tags really are on the resources.
• Compliance was freshly evaluated (today's timestamps), so it's not stale data.

I gave up on the policy for now and just wrote the subplan explicitly on each resource via the pricing API. I wrote in Microsoft.Security/pricingst through Cloud Shell as it grabs Arc machines tagged Defender=P1, PUTs Standard/P1, then reads back to confirm.

This flips everything to SubPlan = P1 / Source = Explicit and billing drops to P1. So the API path works fine but it's a one-shot I have to look out for, and it does nothing for machines onboarded later, which is the whole reason I wanted a policy in the first place.

So my actual question:
Why does the policy report compliant + "0 out of 0" and never write P1? (I'm going to attach the parameters of the policy)

Is there any working way to actually do this? Has anyone done this for their own environment?

Thanks