Advanced Hunting Custom detection rule notification cannot be customized
Hello, We have a case with both Microsoft and US cloud about the custom detection rule created by a query. The problem that we have is that I want to send the rule's notification to an email group. However, after about 2 months of investigations, I was advised below: "We can go one of two routes. Either the alerts from Defender can be ingested into sentinel based on the custom detection rule you created, or the Entra Sign-in logs can be ingested allowing Sentinel to check the logs itself." Could you please help us find an easier solution for the notification or create a feature request so that we could have the configuration of notification for custom detection rules when creating the alert?
Disable Defender for Cloud Apps alerts
Hi all, we just enabled Defender for Cloud Apps in our environment (about 500 clients). We started with setting about 300 apps to "Unsanctioned". Now we get flooded with alerts. Mainly "Connection to a custom network indicator on one endpoint" and "Multi-stage incident on multiple endpoints" when an URL is blocked on more clients. Is there a possibility to disable the alerts for this kind of blocks? I tried creating a supression rules, but didnt manage to get it working. Dont know if it is not possible or if I made a mistake. As the Defender for Cloud Apps just creates a Indicator for every app i want to block I could click every single Indicator and disable the alert there. But thats a few hundred Indicators and we plan to extend the usage. Can I centrally disable alerts for custom indicators? Thanks & Cheers
How to exclude IPs & accounts from Analytic Rule, with Watchlist?
We are trying to filter out some false positives from a Analytic rule called "Service accounts performing RemotePS". Using automation rules still gives a lot of false mail notifications we don't want so we would like to try using a watchlist with the serviceaccounts and IP combination we want to exclude. Anyone knows where and what syntax we would need to exlude the items on the specific Watchlist? Query: let InteractiveTypes = pack_array( // Declare Interactive logon type names 'Interactive', 'CachedInteractive', 'Unlock', 'RemoteInteractive', 'CachedRemoteInteractive', 'CachedUnlock' ); let WhitelistedCmdlets = pack_array( // List of whitelisted commands that don't provide a lot of value 'prompt', 'Out-Default', 'out-lineoutput', 'format-default', 'Set-StrictMode', 'TabExpansion2' ); let WhitelistedAccounts = pack_array('FakeWhitelistedAccount'); // List of accounts that are known to perform this activity in the environment and can be ignored DeviceLogonEvents // Get all logon events... | where AccountName !in~ (WhitelistedAccounts) // ...where it is not a whitelisted account... | where ActionType == "LogonSuccess" // ...and the logon was successful... | where AccountName !contains "$" // ...and not a machine logon. | where AccountName !has "winrm va_" // WinRM will have pseudo account names that match this if there is an explicit permission for an admin to run the cmdlet, so assume it is good. | extend IsInteractive=(LogonType in (InteractiveTypes)) // Determine if the logon is interactive (True=1,False=0)... | summarize HasInteractiveLogon=max(IsInteractive) // ...then bucket and get the maximum interactive value (0 or 1)... by AccountName // ... by the AccountNames | where HasInteractiveLogon == 0 // ...and filter out all accounts that had an interactive logon. // At this point, we have a list of accounts that we believe to be service accounts // Now we need to find RemotePS sessions that were spawned by those accounts // Note that we look at all powershell cmdlets executed to form a 29-day baseline to evaluate the data on today | join kind=rightsemi ( // Start by dropping the account name and only tracking the... DeviceEvents // ... | where ActionType == 'PowerShellCommand' // ...PowerShell commands seen... | where InitiatingProcessFileName =~ 'wsmprovhost.exe' // ...whose parent was wsmprovhost.exe (RemotePS Server)... | extend AccountName = InitiatingProcessAccountName // ...and add an AccountName field so the join is easier ) on AccountName // At this point, we have all of the commands that were ran by service accounts | extend Command = tostring(extractjson('$.Command', tostring(AdditionalFields))) // Extract the actual PowerShell command that was executed | where Command !in (WhitelistedCmdlets) // Remove any values that match the whitelisted cmdlets | summarize (Timestamp, ReportId)=arg_max(TimeGenerated, ReportId), // Then group all of the cmdlets and calculate the min/max times of execution... make_set(Command, 100000), count(), min(TimeGenerated) by // ...as well as creating a list of cmdlets ran and the count.. AccountName, AccountDomain, DeviceName, DeviceId // ...and have the commonality be the account, DeviceName and DeviceId // At this point, we have machine-account pairs along with the list of commands run as well as the first/last time the commands were ran | order by AccountName asc // Order the final list by AccountName just to make it easier to go through | extend HostName = iff(DeviceName has '.', substring(DeviceName, 0, indexof(DeviceName, '.')), DeviceName) | extend DnsDomain = iff(DeviceName has '.', substring(DeviceName, indexof(DeviceName, '.') + 1), "")
Incident Missing Entities
Good morning! I would like to have some clarification on how entities work. Yesterday I found out that if I have 2 entities of the same type (In this particular case, two entities of the type Account), with the same identifier (originally, both share the identifier 'Name'), Sentinel appears to throw away one of them, or both in some instances, and when the alert generates an incident, the entities defined won't appear. I have switched out the identifier on both account types to something different, but until an incident gets triggered, I can't confirm if this will fix the original issue. So my questions are An analytic rule can or can't have two entities of the same type defined? If yes, that means that they need to have different identifiers. Is this a correct asumption? Some identifiers expect a certain type of value to be assigned, that means that eventually, I can ran out of identifiers for my entities or face the added complexity of dealing with types when returning values from my KQL query What could happen if I map an identifier to something that matches the type but not what that identifier represents? in this case, for Account, we have the identifier ObjectGuid. If I assign a value type string to it, that is not a guid, wouldn't that mess up something else in the background? Example, incident grouping If I move instead to use Sentinel Entities, which appear to be the 'general' option, I could only use one, since I only have 'entity' as available identifier, looping back to the problem of can have only one type of identifier for identity type. Thanks in advance
New innovations to protect custom AI applications with Defender for Cloud
Today’s blog post introduced new capabilities to enhance AI security and governance across multi-model and multi-cloud environments. This follow-on blog post dives deeper into how Microsoft Defender for Cloud can help organizations protect their custom-built AI applications. The AI revolution has been transformative for organizations, driving them to integrate sophisticated AI features and products into their existing systems to maintain a competitive edge. However, this rapid development often outpaces their ability to establish adequate security measures for these advanced applications. Moreover, traditional security teams frequently lack the visibility and actionable insights needed, leaving organizations vulnerable to increasingly sophisticated attacks and struggling to protect their AI resources. To address these challenges, we are excited to announce the general availability (GA) of threat protection for AI services, a capability that enhances threat protection in Microsoft Defender for Cloud. Starting May 1, 2025, the new Defender for AI Services plan will support models in Azure AI and Azure OpenAI Services. Note: Effective August 1, 2025, the price for Defender for AI Services was updated to $0.0008 per 1,000 tokens per month (USD – list price). “Security is paramount at Icertis. That’s why we've partnered with Microsoft to host our Contract Intelligence platform on Azure, fortified by Microsoft Defender for Cloud. As large language models (LLMs) became mainstream, our Icertis ExploreAI Service leveraged generative AI and proprietary models to transform contract management and create value for our customers. Microsoft Defender for Cloud emerged as our natural choice for the first line of defense against AI-related threats. It meticulously evaluates the security of our Azure OpenAI deployments, monitors usage patterns, and promptly alerts us to potential threats. These capabilities empower our Security Operations Center (SOC) teams to make more informed decisions based on AI detections, ensuring that our AI-driven contract management remains secure, reliable, and ahead of emerging threats.” Subodh Patil, Principal Cyber Security Architect at Icertis With these new threat protection capabilities, security teams can: Monitor suspicious activity in Azure AI resources, abiding by security frameworks like the OWASP Top 10 threats for LLM applications to defend against attacks on AI applications, such as direct and indirect prompt injections, wallet abuse, suspicious access to AI resources, and more. Triage and act on detections using contextual and insightful evidence, including prompt and response evidence, application and user context, grounding data origin breadcrumbs, and Microsoft Threat Intelligence details. Gain visibility from cloud to code (right to left) for better posture discovery and remediation by translating runtime findings into posture insights, like smart discovery of grounding data sources. Requires Defender CSPM posture plan to be fully utilized. Leverage frictionless onboarding with one-click, agentless enablement on Azure resources. This includes native integrations to Defender XDR, enabling advanced hunting and incident correlation capabilities. Detect and protect against AI threats Defender for Cloud helps organizations secure their AI applications from the latest threats. It identifies vulnerabilities and protects against sophisticated attacks, such as jailbreaks, invisible encodings, malicious URLs, and sensitive data exposure. It also protects against novel threats like ASCII smuggling, which could otherwise compromise the integrity of their AI applications. Defender for Cloud helps ensure the safety and reliability of critical AI resources by leveraging signals from prompt shields, AI analysis, and Microsoft Threat Intelligence. This provides comprehensive visibility and context, enabling security teams to quickly detect and respond to suspicious activities. Prompt analysis-based detections aren’t the full story. Detections are also designed to analyze the application and user behavior to detect anomalies and suspicious behavior patterns. Analysts can leverage insights into user context, application context, access patterns, and use Microsoft Threat Intelligence tools to uncover complex attacks or threats that escape prompt-based content filtering detectors. For example, wallet attacks are a common threat where attackers aim to cause financial damage by abusing resource capacity. These attacks often appear innocent because the prompts' content looks harmless. However, the attacker's intention is to exploit the resource capacity when left unconstrained. While these prompts might go unnoticed as they don't contain suspicious content, examining the application's historical behavior patterns can reveal anomalies and lead to detection. Respond and act on AI detections effectively The lack of visibility into AI applications is a real struggle for security teams. The detections contain evidence that is hard or impossible for most SOC analysts to access. For example, in the below credential exposure detection, the user was able to solicit secrets from the organizational data connected to the Contoso Outdoors chatbot app. How would the analyst go about understanding this detection? The detection evidence shows the user prompt and the model response (secrets are redacted). The evidence also explicitly calls out what kind of secret was exposed. The prompt evidence of this suspicious interaction is rarely stored, logged, or accessible anywhere outside the detection. The prompt analysis engine also tied the user request to the model response, making sense of the interaction. What is most helpful in this specific detection is the application and user context. The application name instantly assists the SOC in determining if this is a valid scenario for this application. Contoso Outdoors chatbot is not supposed to access organizational secrets, so this is worrisome. Next, the user context reveals who was exposed to the data, through what IP (internal or external) and their supposed intention. Most AI applications are built behind AI gateways, proxies, or Azure API Management (APIM) instances, making it challenging for SOC analysts to obtain these details through conventional logging methods or network solutions. Defender for Cloud addresses this issue by using a straightforward approach that fetches these details directly from the application’s API request to Azure AI. Now, the analyst can reach out to the user (internal) or block (external) the identity or the IP. Finally, to resolve this incident, the SOC analyst intends to remove and decommission the secret to mitigate the impact of the exposure. The final piece of evidence presented reveals the origin of the exposed data. This evidence substantiates the fact that the leak is genuine and originates from internal organizational data. It also provides the analyst with a critical breadcrumb trail to successfully remove the secret from the data store and communicate with the owner on next steps. Trace the invisible lines between your AI application and the grounding sources Defender for Cloud excels in continuous feedback throughout the application lifecycle. While posture capabilities help triage detections, runtime protection provides crucial insights from traffic analysis, such as discovering data stores used for grounding AI applications. The AI application's connection to these stores is often hidden from current control or data plane tools. The credential leak example provided a real-world connection that was then integrated into our resource graph, uncovering previously overlooked data stores. Tagging these stores improves attack path and risk factor identification during posture scanning, ensuring safe configuration. This approach reinforces the feedback loop between runtime protection and posture assessment, maximizing cloud-native application protection platform (CNAPP) effectiveness. Align with AI security frameworks Our guiding principle is widely recognized by OWASP Top 10 for LLMs. By combining our posture capabilities with runtime monitoring, we can comprehensively address a wide range of threats, enabling us to proactively prepare for and detect AI-specific breaches with Defender for Cloud. As the industry evolves and new regulations emerge, frameworks such as OWASP, the EU AI Act, and NIST 600-1 are shaping security expectations. Our detections are aligned with these frameworks as well as the MITRE ATLAS framework, ensuring that organizations stay compliant and are prepared for future regulations and standards. Get started with threat protection for AI services To get started with threat protection capabilities in Defender for Cloud, it’s as simple as one-click to enable it on your relevant subscription in Azure. The integration is agentless and requires zero intervention in the application dev lifecycle. More importantly, the native integration directly inside Azure AI pipeline does not entail scale or performance degradation in the application runtime. Consuming the detections is easy, it appears in Defender for Cloud’s portal, but is also seamlessly connected to Defender XDR and Sentinel, leveraging the existing connectors. SOC analysts can leverage the correlation and analysis capabilities of Defender XDR from day one. Explore these capabilities today with a free 30-day trial*. You can leverage your existing AI application and simply enable the “AI workloads” plan on your chosen subscription to start detecting and responding to AI threats. *Trial free period is limited to up to 75B tokens scanned. Learn more about the innovations designed to help your organization protect data, defend against cyber threats, and stay compliant. Join Microsoft leaders online at Microsoft Secure on April 9. Explore additional resources Learn more about Runtime protection Learn more about Posture capabilities Watch the Defender for Cloud in the Field episode on securing AI applications Get started with Defender for Cloud
Unable to add Endpoints and Vulnerability management in XDR Permissions
Hi, I have defender for endpoint running on obver 400 devices. I have 10 with Bus Premium, 5 with E5, and the rest E3. I am getting incidents for DFE, and this is being sent to my SOAR platform for analysis, but when I pivot back using client-sync, I cannot see DFE incidents. I have gone into Settings > XDR > Workload settings, and can only see the below There does not appear to be the option to grant the roles I have provided for my SOAR user the ability to see Endpoint and Vulnerability management. Really scratching my head here. Help?AZ-500: Microsoft Azure Security Technologies Study Guide
The AZ-500 certification provides professionals with the skills and knowledge needed to secure Azure infrastructure, services, and data. The exam covers identity and access management, data protection, platform security, and governance in Azure. Learners can prepare for the exam with Microsoft's self-paced curriculum, instructor-led course, and documentation. The certification measures the learner’s knowledge of managing, monitoring, and implementing security for resources in Azure, multi-cloud, and hybrid environments. Azure Firewall, Key Vault, and Azure Active Directory are some of the topics covered in the exam.Interface Views in Microsoft 365 Admin Center
1. Simplified View Purpose: Designed for small businesses or organizations with limited IT resources. Features: Streamlined dashboard with essential tasks like user management, license assignment, and password resets. Minimal configuration options to reduce complexity. Quick access to support and basic service health info. Use Case: Ideal for admins who need to perform routine tasks without diving into advanced settings. 2. Dashboard View (Advanced View) Purpose: Tailored for medium to large enterprises with complex IT environments. Features: Full access to all admin centers (Exchange, SharePoint, Teams, etc.). Advanced analytics, reporting, and configuration tools. Role-based access control and security management. Customizable widgets and navigation for personalized workflows. Use Case: Suitable for IT teams managing multiple services, users, and compliance requirements. Customization Needs Are there specific tasks we perform frequently that can be automated in the dashboard?
