Hi all I use XDR unified services and purview is one of those applications that just randomly stopped sending its alerts to XDR and sentinel. Anyone seen this before or know what why this would happen. I’ve been looking into it for a while few hours and so far coming up with it could be a tenant thing or purview update policy. I know it’s something small.

I'm working on Snarely, an early research project, not a product. I've been looking at data from one deliberately exposed honeypot collected in Microsoft Sentinel. The dataset has passed 100,000 event records.

I'm trying to make the page useful as a small data report, not a product pitch. For people who work with Sentinel or honeypot data:

• Which measurements or breakdowns would help you judge whether the patterns are meaningful?
• What would you want documented to make the collection and limitations clear?

Event records aren't attacker counts, and I'm not making attribution claims. I'd value specific technical criticism.

Just a FYi,

It appears Data Lake will now be integrated for all Sentinel users (if they haven't enabled data lake before then)

"Going forward, you do not need to go through a separate data lake onboarding and billing setup. You complete the Microsoft Sentinel onboarding and verify your Sentinel workspace is connected to the Defender portal. Once this is completed, you can enable the lake tier by using Table management in the Defender portal to extend retention on a data table."

What's new in Microsoft Sentinel | Microsoft Learn

I'm looking to create a Sentinel report/workbook that shows all the systems currently sending logs into Sentinel.

I'd like it to show:

• Hostname
• IP address
• Log table/source
• Event count

We're using WEF/WEC for some Windows logs, so I'd also like to identify the actual originating device, not just the WEC server if that is possible.

What's the best KQL approach for building this type of log-source inventory? Is there also a good way to identify the device type, such as Domain Controller, SQL Server, etc.? Feel free to give any advice possible for this situation.

Amigos, cuál es aquel playbook que para ustedes es esencial para proteger una organización?

I for the life of me cannot figure out why my Playbook is visible in the Defender portal under Sentinel Automation, but I am unable to use it in any automation rules. Based on the documentation url listed under the grayed out Playbook, I have added the permissions for the service principal. The workspace lives in the same subscription under a different resource group than the Teams notification Playbook I am trying to configure. Has anyone ran into this issue before? I am new to Sentinel in general so I did not get to experience the old location in Azure as it now redirects to the Defender portal. It also seems like most of Microsoft’s current documentation refers to the “old” way of configuring playbooks in Azure.

A context graph is described as a persistent layer linking telemetry with organizational knowledge, asset ownership, tickets, prior investigations, so an AI system can interpret alerts without querying raw logs from scratch every time. If that's how it works, could a mature context graph reduce how much raw historical data you actually need retained in an expensive SIEM tier, since the graph already holds the relevant relationships rather than requiring a fresh query across raw logs? Or does the graph just sit on top of the SIEM without changing the underlying retention need at all.

Herkese merhaba

Geçtiğimiz birkaç ay boyunca, düzenlenmiş Kubernetes ortamlarında tekrar eden bir sorunu çözmek için çalışıyoruz: tedarik zinciri onayları, kabul politikaları ve denetime hazır uyumluluk raporlaması arasındaki boşluğu, operasyonel verileri harici SaaS satıcılarına aktarmadan kapatmak.

Kesinlikle küme içinde çalışan ve görüntü geçişinden kurcalamaya dayanıklı uyumluluk kanıtlarına kadar tüm yaşam döngüsünü işleyen, kendi kendine barındırılan bir mekanizma istedik. İşte üzerinde karar kıldığımız mimari ve yaklaşım:

* **Giriş ve Tedarik Zinciri Geçidi:** Bölmenin yürütülmesinden önce Cosign imzaları, SLSA kaynağı ve SBOM kontrolleri yoluyla politikaya dayalı kabulün uygulanması. Sadece CVSS puanlarını engellemek yerine CISA KEV eşleştirmeyi ve temel görüntü EOL tespitini dahil ettik. * **OpenVEX Kullanımı:** Yalnızca güvenilir imzalayanların bulguları otomatik olarak reddedebilmesini sağlamak için tedarikçi OpenVEX onaylarını kriptografik olarak doğrulamak. * **Kuru Çalıştırma ve Acil Durum Baypasları:** Cam kırma senaryoları için zorunlu kayıt işleminin yanı sıra, politika etkisini önizlemek için geçmiş dağıtım kararlarına karşı ne olursa olsun analizi eklendi. * **Kriptografik Kanıt Paketleme:** Denetimler için ham CSV'leri veya JSON'ları dışa aktarmak yerine, kanıt paketleri (PDF'ler ve SOC 2, ISO 27001, NIS2 ve CRA gibi çerçevelerle eşlenen yapılandırılmış raporlar) bir DSSE zarfı içinde imzalanır. Denetçiler, küme erişimine ihtiyaç duymadan kümenin genel anahtarı aracılığıyla orijinalliği doğrulayabilir. * **Çalışma Zamanı Eşlemesi:** Falco çalışma zamanı uyarılarını kabul politikası kararlarına ve ilk görüntü meta verilerine geri bağlamak. * **Kesin Gizlilik:** Sıfır telemetri veya tarama sonucu sızıntısı—her şey küme kontrol düzlemi içinde kalır.

Sıkı uyumluluk veya hava boşluklu iş yükleri kullananlar için: şu anda dış denetçiler için kurcalamaya dayanıklı kanıt toplama işlemini nasıl gerçekleştiriyorsunuz ve kırılma camı iş akışınız politikanın uygulanması açısından nasıl görünüyor?

I have over 4 years of SOC Analyst experience using Azure Security tools. I want to move into Engineering. Using a free tier azure account I practiced an Automation where i enriched an IP with VirusTotal API, sent the incident details with a revoke session button in an email using gmail connector in logic apps . I want to learn few more Automations to explain in the interview. Any Automation ideas that can be practiced using the free tier are appreciated.

I'm interested in how people actually create realistic cloud activity when learning and testing things like cloud detections, SIEM rules, incident investigations, or security tooling.

For example, if you wanted to test whether your security monitoring could detect something happening in Azure, how would you create the activity?

Would you:

• Perform everything manually?
• Use scripts/APIs?
• Use attack simulation frameworks?
• Use Terraform or another IaC approach?
• Build dedicated test environments?
• Replay existing telemetry?
• Use intentionally vulnerable labs?
• Something else?

What happens after the initial setup?

How do you keep the environment producing realistic activity rather than becoming a static environment that nobody touches?

What is the most annoying part of this process today?

I'm trying to understand the real-world workflow rather than looking for tool recommendations.

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