From visibility to action: The power of cloud detection and response
Cloud attacks aren’t just growing—they’re evolving at a pace that outstrips traditional security measures. Today’s attackers aren’t just knocking at the door—they’re sneaking through cracks in the system, exploiting misconfigurations, hijacking identity permissions, and targeting overlooked vulnerabilities. While organizations have invested in preventive measures like vulnerability management and runtime workload protection, these tools alone are no longer enough to stop sophisticated cloud threats. The reality is: security isn’t just about blocking threats from the start—it’s about detecting, investigating, and responding to them as they move through the cloud environment. By continuously correlating data across cloud services, cloud detection and response (CDR) solutions empower security operations centers (SOCs) with cloud context, insights, and tools to detect and respond to threats before they escalate. However, to understand CDR’s role in the broader cloud security landscape, let’s first understand how it evolved from traditional approaches like cloud workload protection (CWP). The natural progression: From protecting workloads to correlating cloud threats In today’s multi-cloud world, securing individual workloads is no longer enough—organizations need a broader security strategy. Microsoft Defender for Cloud offers cloud workload protection as part of its broader Cloud-Native Application Protection Platform (CNAPP), securing workloads across Azure, AWS, and Google Cloud Platform. It protects multicloud and on-premises environments, responds to threats quickly, reduces the attack surface, and accelerates investigations. Typically, CWP solutions work in silos, focusing on each workload separately rather than providing a unified view across multiple clouds. While this solution strengthens individual components, it lacks the ability to correlate the data across cloud environments. As cloud threats become more sophisticated, security teams need more than isolated workload protection—they need context, correlation, and real-time response. CDR represents the natural evolution of CWP. Instead of treating security as a set of isolated defenses, CDR weaves together disparate security signals to provide richer context, enabling faster and more effective threat mitigation. A shift towards a more unified, real-time detection and response model, CDR ensures that security teams have the visibility and intelligence needed to stay ahead of modern cloud threats. If CWP is like securing individual rooms in a building—locking doors, installing alarms, and monitoring each space separately—then CDR is like having a central security system that watches the entire building, detecting suspicious activity across all rooms, and responding in real time. That said, building an effective CDR solution comes with its own challenges. These are the key reasons your cloud security strategy might be falling short: Lack of Context SOC teams can’t protect what they can’t see. Limited visibility and understanding into resource ownership, deployment, and criticality makes threat prioritization difficult. Without context, security teams struggle to distinguish minor anomalies from critical incidents. For example, a suspicious process in one container may seem benign alone but, in context, could signal a larger attack. Without this contextual insight, detection and response are delayed, leaving cloud environments vulnerable. Hierarchical Complexity Cloud-native environments are highly interconnected, making incident investigation a daunting task. A single container may interact with multiple services across layers of VMs, microservices, and networks, creating a complex attack surface. Tracing an attack through these layers is like finding a needle in a haystack—one compromised component, such as a vulnerable container, can become a steppingstone for deeper intrusions, targeting cloud secrets and identities, storage, or other critical assets. Understanding these interdependencies is crucial for effective threat detection and response. Ephemeral Resources Cloud native workloads tend to be ephemeral, spinning up and disappearing in seconds. Unlike VMs or servers, they leave little trace for post-incident forensics, making attack investigations difficult. If a container is compromised, it may be gone before security teams can analyze it, leaving minimal evidence—no logs, system calls, or network data to trace the attack’s origin. Without proactive monitoring, forensic analysis becomes a race against time. A unified SOC experience with cloud detection and response The integration of Microsoft Defender for Cloud with Defender XDR empowers SOC teams to tackle modern cloud threats more effectively. Here’s how: 1. Attack Paths One major challenge for CDR is the lack of context. Alerts often appear isolated, limiting security teams’ understanding of their impact or connection to the broader cloud environment. Integrating attack paths into incident graphs can improve CDR effectiveness by mapping potential routes attackers could take to reach high-value assets. This provides essential context and connects malicious runtime activity with cloud infrastructure. In Defender XDR, using its powerful incident technology, alerts are correlated into high-fidelity incidents and attack paths are included in incident graphs to provide a detailed view of potential threats and their progression. For example, if a compromised container appears on an identified attack path leading to a sensitive storage account, including this path in the incident graph provides SOC teams with enhanced context, showing how the threat could escalate. Attack path integrated into incident graph in Defender XDR, showing potential lateral movement from a compromised container. 2. Automatic and Manual Asset Criticality Classification In a cloud native environment, it’s challenging to determine which assets are critical and require the most attention, leading to difficulty in prioritizing security efforts. Without clear visibility, SOC teams struggle to identify relevant resources during an incident. With Microsoft’s automatic asset criticality, Kubernetes clusters are tagged as critical based on predefined rules, or organizations can create custom rules based on their specific needs. This ensures teams can prioritize critical assets effectively, providing both immediate effectiveness and flexibility in diverse environments. Asset criticality labels are included in incident graphs using the crown shown on the node to help SOC teams identify that the incident includes a critical asset. 3. Built-In Queries for Deeper Investigation Investigating incidents in a complex cloud-native environment can be overwhelming, with vast amounts of data spread across multiple layers. This complexity makes it difficult to quickly investigate and respond to threats. Defender XDR simplifies this process by providing immediate, actionable insights into attacker activity, cutting investigation time from hours or days to just minutes. Through the “go hunt” action in the incident graph, teams can leverage pre-built queries specifically designed for cloud and containerized threats, available at both the cluster and pod levels. These queries offer real-time visibility into data plane and control plane activity, empowering teams to act swiftly and effectively, without the need for manual, time-consuming data sifting. 4. Cloud-Native Response Actions for Containers Attackers can compromise a cloud asset and move laterally across various environments, making rapid response critical to prevent further damage. Microsoft Defender for Cloud’s integration with Defender XDR offers real-time, multi-cloud response capabilities, enabling security teams to act immediately to stop the spread of threats. For instance, if a pod is compromised, SOC teams can isolate it to prevent lateral movement by applying network segmentation, cutting off its access to other services. If the pod is malicious,it can be terminated entirely to halt ongoing malicious activity. These actions, designed specifically for Kubernetes environments, allow SOC teams to respond instantly with a single click in the Defender portal, minimizing the impact of an attack while investigation and remediation take place. New innovations for threat detection across workloads, with focused investigation and response capabilities for containers—only with Microsoft Defender for Cloud. New innovations for threat detection across workloads, with focused investigation and response capabilities for containers—only with Microsoft Defender for Cloud. 5. Log Collection in Advanced Hunting Containers are ephemeral and that makes it difficult to capture and analyze logs, hindering the ability to understand security incidents. To address this challenge, we offer advanced hunting that helps ensure critical logs—such as KubeAudit, cloud control plane, and process event logs—are captured in real time, including activities of terminated workloads. These logs are stored in the CloudAuditEvents and CloudProcessEvents tables, tracking security events and configuration changes within Kubernetes clusters and container-level processes. This enriched telemetry equips security teams with the tools needed for deeper investigations, advanced threat hunting, and creating custom detection rules, enabling faster detection and resolution of security threats. 6. Guided response with Copilot Defender for Cloud's integration with Microsoft Security Copilot guides your team through every step of the incident response process. With tailored remediation for cloud native threats, it enhances SOC efficiency by providing clear, actionable steps, ensuring quicker and more effective responses to incidents. This enables teams to resolve security issues with precision, minimizing downtime and reducing the risk of further damage. Use case scenarios In this section, we will follow some of the techniques that we have observed in real-world incidents and explore how Defender for Cloud’s integration with Defender XDR can help prevent, detect, investigate, and respond to these incidents. Many container security incidents target resource hijacking. Attackers often exploit misconfigurations or vulnerabilities in public-facing apps — such as outdated Apache Tomcat instances or weak authentication in tools like Selenium — to gain initial access. But not all attacks start this way. In a recent supply chain compromise involving a GitHub Action, attackers gained remote code execution in AKS containers. This shows that initial access can also come through trusted developer tools or software components, not just publicly exposed applications. After gaining remote code execution, attackers disabled command history logging by tampering with environment variables like “HISTFILE,” preventing their actions from being recorded. They then downloaded and executed malicious scripts. Such scripts start by disabling security tools such as SELinux or AppArmor or by uninstalling them. Persistence is achieved by modifying or adding new cron jobs that regularly download and execute malicious scripts. Backdoors are created by replacing system libraries with malicious ones. Once the required configuration changes are made for the malware to work, the malware is downloaded, executed, and the executable file is deleted to avoid forensic analysis. Attackers try to exfiltrate credentials from environment variables, memory, bash history, and configuration files for lateral movement to other cloud resources. Querying the Instance Metadata service endpoint is another common method for moving from cluster to cloud. Defender for Cloud and Defender XDR’s integration helps address such incidents both in pre-breach and post-breach stages. In the pre-breach phase, before applications or containers are compromised, security teams can take a proactive approach by analyzing vulnerability assessment reports. These assessments surface known vulnerabilities in containerized applications and underlying OS components, along with recommended upgrades. Additionally, vulnerability assessments of container images stored in container registries — before they are deployed — help minimize the attack surface and reduce risk earlier in the development lifecycle. Proactive posture recommendations — such as deploying container images only from trusted registries or resolving vulnerabilities in container images — help close security gaps that attackers commonly exploit. When misconfigurations and vulnerabilities are analyzed across cloud entities, attack paths can be generated to visualize how a threat actor might move laterally across services. Addressing these paths early strengthens overall cloud security and reduces the likelihood of a breach. If an incident does occur, Defender for Cloud provides comprehensive real-time detection, surfacing alerts that indicate both malicious activity and attacker intent. These detections combine rule-based logic with anomaly detection to cover a broad set of attack scenarios across resources. In multi-stage attacks — where adversaries move laterally between services like AKS clusters, Automation Accounts, Storage Accounts, and Function Apps — customers can use the "go hunt" action to correlate signals across entities, rapidly investigate, and connect seemingly unrelated events. Attackers increasingly use automation to scan for exposed interfaces, reducing the time to breach containers—sometimes in under 30 minutes, as seen in a recent Geoserver incident. This demands rapid SOC response to contain threats while preserving artifacts for analysis. Defender for Cloud enables swift actions like isolating or terminating pods, minimizing impact and lateral movement while allowing for thorough investigation. Conclusion Microsoft Defender for Cloud, integrated with Defender XDR, transforms cloud security by addressing the challenges of modern, dynamic cloud environments. By correlating alerts from multiple workloads across Azure, AWS, and GCP, it provides SOC teams with a unified view of the entire threat landscape. This powerful correlation prevents lateral movement and escalation of threats to high-value assets, offering a deeper, more contextual understanding of attacks. Security teams can seamlessly investigate and track incidents through dynamic graphs that map the full attack journey, from initial breach to potential impact. With real-time detection, automatic alert correlation, and the ability to take immediate, decisive actions—like isolating compromised containers or halting malicious activity—Defender for Cloud’s integration with Defender XDR ensures a proactive, effective response. This integrated approach enhances incident response and empowers organizations to stop threats before they escalate, creating a resilient and agile cloud security posture for the future. Additional resources: Watch this cloud detection and response video to see it in action Try our alerts simulation tool for container security Read about some of our recent container security innovations Check out our latest product releases Explore our cloud security solutions page Learn how you can unlock business value with Defender for Cloud Start a free 30-day trial of Defender for Cloud today
Optimisation For Abnormal Deny Rate for Source IP
Hi, I have recently enabled the "Abnormal Deny Rate for Source IP" alert in Microsoft Sentinel and found it to be quite noisy, generating a large number of alerts many of which do not appear to be actionable. I understand that adjusting the learning period is one way to reduce this noise. However, I am wondering if there are any other optimisation strategies available that do not involve simply changing the learning window. Has anyone had success with tuning this rule using: Threshold-based suppression (e.g. minimum deny count)? Source IP allowlists? Frequency filters (e.g. repeated anomalies over multiple intervals)? Combining with other signal types before generating alerts? Open to any suggestions, experiences, or best practices that others may have found effective in reducing false positives while still maintaining visibility into meaningful anomalies. Thanks in advance,
The Risk of Default Configuration: How Out-of-the-Box Helm Charts Can Breach Your Cluster
Authors: Michael Katchinskiy, Security Researcher, Microsoft Defender for Cloud Research Yossi Weizman, Principal Security Research Manager, Microsoft Defender for Cloud Research Have you ever used pre-made deployment templates to quickly spin up applications in Kubernetes environments? While these “plug-and-play” options greatly simplify the setup process, they often prioritize ease of use over security. As a result, a large number of applications end up being deployed in a misconfigured state by default, exposing sensitive data, cloud resources, or even the entire environment to attackers. Cloud-native applications are software systems designed to fully leverage the flexibility and scalability of the cloud. These applications are broken into small services called microservices. Usually, each service is packaged in a container with all its dependences, making it easy to deploy across different environments. Kubernetes then orchestrates these services, automatically handling their deployment, scaling, and health checks. Out-of-the-Box Helm Charts Open-source projects usually contain a section explaining how to deploy their apps “out of the box” on their code repository. These documents often include default manifests or pre-defined Helm charts that are intended for ease of use rather than hardened security. Among other issues, two significant security concerns arise: (1) exposing services externally without proper network restrictions and (2) lack of adequate built-in authentication or authorization by default. Internet exposure in Kubernetes usually originates in a LoadBalancer service, which exposes K8s workloads via an external IP for direct access, or in Ingress objects, which manage HTTP and HTTPS traffic to internal services. If authentication is not properly configured, both can allow insecure access to the applications, leading to unauthorized access, data exposure, and potential service abuse. Consequently, default configurations that lack proper security controls create a severe security threat. Without carefully reviewing the YAML manifests and Helm charts, organizations may unknowingly deploy services lacking any form of protection, leaving them fully exposed to attackers. This is particularly concerning when the deployed application can query sensitive APIs or allow administrative actions, which is exactly what we will shortly see. Apache Pinot default configuration Apache Pinot is a real-time, distributed OLAP datastore designed for high-speed querying of large-scale datasets with low latency. For Kubernetes installations, Apache Pinot’s official documentation refers users to a Helm chart stored in their official Github repository for a quick installation: While Apache Pinot's documentation states that the provided configuration is a reference setup that users may want to modify, they don’t mention that this configuration is severely insecure, leaving the users prone to data theft attacks: The default installation exposes Apache Pinot’s main components to the internet by Kubernetes LoadBalancer services without providing any authentication mechanism by default. Specifically, the pinot-broker and pinot-controller services allow unauthenticated access to query the stored data and manage the workload. Below is a screenshot of Pinot’s dashboard, exposed by the pinot-controller service in port 9000, allowing full management of the Apache Pinot and access to the stored information. Recently, Microsoft Defender for Cloud identified several incidents in which attackers exploited misconfigured Apache Pinot workloads, allowing them to access the data of Apache Pinot users. Not Just Apache Pinot To determine how widespread this issue is, we conducted a thorough investigation by searching using GitHub Code Search repositories for YAML files containing strings that may indicate on misconfigured workload, such as “type: LoadBalancer”. We then sorted the results by their popularity and deployed the applications in controlled test environments to assess their default security posture. Our goal was to find out which applications are exposed to the internet by default, more critically, whether they incorporate any authentication or authorization mechanisms. Here's what we found: The majority of applications we evaluated had at least some form of basic password protection, though the strength and reliability of these measures varied significantly. A small but critical group of applications either provided no authentication at all or used a predefined user and password for logging in, making them prime targets for attackers. Sign me up Several applications appeared secure at first glance, but they allowed anyone to create a new account and access the system. This clearly does not provide effective protection when exposed to the internet. This highlights how a “default by convenience” approach can invite risk when security settings are not thoroughly reviewed or properly configured. Meshery is an engineering platform for collaborative design and operation of cloud native infrastructure. By default, when installing Meshery on your Kuberentes cluster via the official Helm installation, the app’s interface is exposed via an external IP address. We discovered that anyone who can access the external IP address can sign up with a new user and access the interface which provides extensive visibility into cluster activities and even enable the deployment of new pods. These capabilities grant attackers a direct path to execute arbitrary code and gain control of underlying resources if Meshery is not secured or restricted to internal networks only. Selenium Grid Selenium is a popular tool for automating web browser testing, with millions of downloads of its container image. In the last few months, we’ve observed multiple attack campaigns specifically targeting Selenium Grid instances that lack authentication. In addition several security vendors, including Wiz and Cado Security, have reported these attacks. While the official Helm chart for Selenium Grid doesn’t expose it to the internet, there are several widely referenced GitHub projects that do - using a LoadBalancer or a NodePort. In one Selenium deployment example from the official Kubernetes repository, Selenium is set up to use a NodePort. This configuration exposes the service on a specific port across all nodes in your cluster, meaning that the firewall rules set up in your network security group become your primary and often only line of defense. If you'd like to see additional examples, try using GitHub Code Search with this query. Awareness of the risks associated with exposing services has grown over the years, and many developers today understand the dangers of leaving applications wide open. Even so, some applications simply weren’t built for external access and don’t provide any built-in authentication. Their own documentation often warns users not to expose these services publicly. Yet, it still happens, usually for convenience, leaving entire clusters at risk. If you still remain unconvinced, look to the countless unsecured Redis, Elasticsearch, Prometheus, and other instances that are regularly surfaced in Shodan scans and security blog posts. Despite years of warnings, these applications are still being exposed. Conclusion Many in-the-wild exploitations of containerized applications originate in misconfigured workloads, often when using default settings. Relying on “default by convenience” setups pose a significant security risk. To mitigate these risks, it is crucial to: Review before you deploy: Don’t rely on default configurations. Review the configuration files and modify them according to security best practices. This includes enforcing strong authentication mechanism and network isolation. Regularly scan your organization to exposed services: Scan the publicly facing interfaces of your workloads. While some workloads should allow access from external endpoints, in many cases this exposure should be reconsidered. Monitor your containerized applications: Monitor the running containers in your environment for malicious and suspicious activities. This includes monitoring of the running processes, network traffic, and other activities performed by the workload. Also, many container-based attacks involve deployment of backdoor containers in the cluster. Monitor the Kubernetes cluster for unknown workloads and the nodes for unknown pulled images. Strengthening Cluster Security with Microsoft Defender for Cloud Microsoft Defender for Cloud (MDC) helps protect your environment from misconfigurations, including risky service exposure. For example, MDC alerts on the exposure of Kubernetes services which are associated with sensitive interfaces, including Apache Pinot. With Microsoft Defender CSPM, you can get an overview of the exposure of your organization’s cloud environment, including the containerized applications. Using the Cloud Security Explorer, you can get full visibility of the internet exposed workloads in your Kubernetes clusters, enabling you to mitigate potential risks and easily identify misconfiguration. Read more about Containers security with Microsoft Defender for containers here.
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), "")Validating Microsoft Defender for App Service Alerts
Disclaimer This document is provided “as is.” MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT. This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes. Introduction Microsoft Defender for App Service helps organizations be more secure by providing dedicated security analytics for your App Service resources. The purpose of this article is to provide specific guidance on how to validate Microsoft Defender for App Service alerts, by simulating a suspicious activity on applications running over App Service. Preparation The first step in validating Microsoft Defender alerts for App Service is to ensure that Microsoft Defender for App Service is enabled on the subscription(s) as shown in Figure 1, that you want to use to validate the alert. Enabling Microsoft Defender for App Service provides monitoring and threat detection for a multitude of threats to your App Service resources. Additionally, enabling Microsoft Defender for App Service, surfaces security findings with recommendations on how to harden your resources covered by the App Service plan. To learn more about Microsoft Defender for App Services, watch this video. Microsoft Defender for Cloud plans can be enabled individually. For the purpose of validating the scenario covered in this article, pre-requisite is to solely enable Microsoft Defender for App Service. After enabling Microsoft Defender for App Service, you need to determine the scenario that you want to validate. Common scenarios that can be simulated range from php uploads, to NMAP scanning, or even Content Management System (CMS) fingerprinting. When determining the scenarios for which you would like to validate alerts, you can also consult the reference guide of Alerts for Azure App Service. Microsoft Defender for App Service alerts are mapped to and cover almost the complete MITRE ATT&CK tactics from pre-attack to command and control, which can be useful when deciding which scenario(s) you wish to simulate. In case you wish to solely test that the pipeline is working, there is also a like alert for App Service which can be invoked by making a web request to a “/This_Will_Generate_ASC_Alert” URI. I.e. if your site is named ‘foo’, making a request to https://foo.azurewebsites.net/This_Will_Generate_ASC_Alert, will generate an alert similar to the one shown in Figure 2. In this article, we will simulate the scenario of accessing a suspicious PHP page located in the upload folder, which will generate the “PHP file in upload folder” alert. This type of folder doesn’t usually contain PHP files and its existence might indicate exploitation taking advantage of arbitrary file upload vulnerabilities. Implementing In order to simulate this scenario, you could either use an existing Web App or create a new one. When creating a new Web App, you can deploy a PHP app to Azure App Service on Linux (as a runtime stack select PHP 7.4) The alert that will be generated applies to both App Service on Linux and Windows. Once you’ve created the App Service Plan and the Web App, install Wordpress 5.8 (including creating an Azure Database for MySQL server). To learn more about how to create a PHP Web App in Azure App Service, read this guidance. Note: In most cases, once a new web site is created, it might take up to 12h for alerts related to a newly created web site to appear. To simulate the scenario of accessing a suspicious PHP page located in the upload folder, a PHP page is required. You can use the sample below to create a test PHP page (shown in Figure 3) and save it as a PHP file. Afterwards, navigate to “/wp-content/uploads/2021/08/” and upload the file. Important: After you’ve uploaded the PHP file to this folder, you need to browse to this PHP page using a browser (similarly to Figure 5). Please note that the output on the page, will depend on the code in your test PHP file. Validating Once Microsoft Defender for App Service generates the alert on target subscription(s), you can find it in the “Security alerts” section of the Microsoft Defender for Cloud dashboard. Selecting the generated alert (in this case “PHP file in upload folder”) will open a blade, which provides more context and rich metadata about the alert (similar to Figure 6). When validating the alerts, be sure to consult the full list of App Service alerts. You can also export Microsoft Defender for Cloud alerts to a SIEM (i.e. Azure Sentinel or 3 rd party SIEM). Learn more about how to stream alerts to a SIEM, SOAR or ITSM. Learn more about how to investigate Microsoft Defender for Cloud alerts using Azure Sentinel. Learn more about Analysing Web Shell Attacks with Microsoft Defender for Cloud data in Azure Sentinel - Microsoft Tech Community. Final Considerations Microsoft Defender for App Service is all about providing threat detection and security recommendations for applications running over App Service. This article focuses on validating alerts for Microsoft Defender for App Service, by simulating a specific scenario, namely accessing a suspicious PHP page located in the upload folder. Properly executing the steps outlined in this article generates the security alert “PHP file in upload folder”. This article is not intended to cover all scenarios, but it does provide real value as you get started with validating Microsoft Defender for App Service alerts. Remember to keep an eye out for other article from this series, which can be found on our official ASC Tech Community. Reviewers: @Yuri Diogenes, Principal PM @Tomer Spivak, Senior PM Contributors: Dotan Patrich, Principal Software Engineer, Yossi Weizman, Senior Security Researcher Ram Pliskin, Senior Security Researcher Manager Lior Arviv, Senior PMNew 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 May 1, 2025, the price for Defender for AI Services will change to $0.002 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 CloudRSAC 2025 new Microsoft Sentinel connectors announcement
Microsoft Sentinel is a leading cloud-native security information and event management (SIEM) solution that helps organizations confidently detect, investigate and respond to threats across their multi-cloud, multiplatform environments. Microsoft Sentinel offers seamless integration of data from both Microsoft and third-party sources for a comprehensive view across the entire digital environment. We are very pleased to share the latest Microsoft Sentinel integrations from our valued Independent Software Vendor (ISV) partners that allow you to seamlessly connect your existing security solutions with Microsoft Sentinel and benefit from robust analytics and automation capabilities to strengthen your defenses against evolving cyber threats. Featured ISVs Google Threat Intelligence for Microsoft Sentinel The Google Threat Intelligence Solution for Microsoft Sentinel integrates Google's extensive threat intelligence with Microsoft Sentinel to enrich security investigations. This solution automates the process of gathering intelligence on indicators like IPs, file hashes, and URLs, providing valuable context and improving the accuracy and efficiency of incident response. Infoblox App for Microsoft Sentinel The Infoblox App for Microsoft Sentinel enhances Security Operations Centers (SOC) by integrating actionable intelligence and contextual network data derived from DNS data into Microsoft Sentinel. This integration provides SOC analysts with tools to quickly identify and respond to potential threats such as malware and data exfiltration, improving overall security posture. This integration offers seamless configuration, intuitive dashboards, and unique DNS-based threat intelligence to streamline threat detection and response. Netskope Data Connector for Microsoft Sentinel Built on the CCP, this connector seamlessly streams CASB alerts, DLP incidents, and threat logs into Microsoft Sentinel, delivering real-time visibility and actionable insights. With a one-click setup and automated data flow, the integration simplifies incident management. This empowers security teams to focus on rapid incident response and proactive policy enforcement, boosting both security posture and operational efficiency. New and notable Dragos Platform for Microsoft Sentinel Integration The Dragos Platform integration with Microsoft Sentinel streamlines IT/OT security by providing visibility into OT assets, threats, and vulnerabilities for industrial environments. This integration enables customers to seamlessly incorporate OT-specific threat detection into their existing IT security workflows, creating a unified approach to managing alerts. Jamf Protect for Microsoft Sentinel The Jamf Protect for Microsoft Sentinel solution provides comprehensive Apple Endpoint Security insights by integrating detailed event data from macOS endpoints into a Microsoft Sentinel workspace. This integration offers full visibility into security events through Workbooks, Analytic Rules, and Unified Logging events captured by Jamf Protect. Additionally, it includes tools such as Hunting Queries, Playbooks, and a Data Connector to enhance incident investigation and automated actions. Trigger Torq Workflows from Microsoft Sentinel Incidents The Torq Sentinel Solution triggers Torq workflows directly from Microsoft Sentinel incidents, simplifying the setup process and streamlining the deployment of Hyperautomated Microsoft Sentinel workflows. When new incidents are created or existing incidents are updated in Microsoft Sentinel, Torq leverages Hyperautomation and agentic AI to help eliminate false positives, create and prioritize comprehensive security cases, and help autonomously remediate incidents to enhance SOC teams’ efficiency. ZeroFox Alerts & CTI Connectors for Microsoft Sentinel The ZeroFox Alerts & CTI Connectors for Microsoft Sentinel allows you to ingest ZeroFox alert data into Microsoft Sentinel. This integration leverages a global data collection engine, AI-based analysis, and automated remediation to help protect your digital assets and data from threats at the scale and speed of the internet. It enables organizations to visualize and analyze these threats directly from Microsoft Sentinel, improving security posture through correlation with other internal IT and security data sources. Solutions now available for Microsoft Sentinel Microsoft Sentinel now offers a range of solutions. Alongside commercially supported integrations, the Microsoft Sentinel content hub connects you to hundreds of community-based solutions and thousands of practitioner contributions. You can find more details and setup instructions for these integrations via the content hub in Microsoft Sentinel. Microsoft’s Sentinel Promise to customers For customers migrating to Sentinel, Microsoft offers the Sentinel Promise program backed by App Assure. This initiative ensures ISVs receive the support they need to build high-quality connectors. Read our recent announcement to learn how our Sentinel Promise helps promote seamless integration of your essential data sources. Message to our partners We deeply appreciate the unwavering collaboration and valuable contributions of our partners. Your steadfast partnership has been crucial in delivering the most comprehensive, timely insights and security value to our mutual customers. We are grateful to be working together to enhance the security landscape. Security is indeed a team effort, and your dedication and innovation are instrumental in our collective success. We aim for these new partner solutions to provide significant value and welcome your feedback and suggestions. We continually work on enhancing Microsoft Sentinel and expanding its partner ecosystem. Please stay informed of further updates and announcements. Learn more Microsoft’s commitment to security Microsoft’s Secure Future Initiative Unified SecOps | SIEM and XDR solutions Unified Platform documentation | Microsoft Defender XDR What else is new with Microsoft Sentinel? Microsoft Sentinel product home Microsoft Sentinel content hub catalog Microsoft's Sentinel Promise What’s new with Microsoft Sentinel at Secure 2025 Exciting new Microsoft Sentinel connectors announcement at Ignite 2024 Additional resources Best practices for partners integrating with Microsoft Sentinel What's New: Create your own codeless data connector Latest Microsoft Tech Community Sentinel blog announcements Microsoft Sentinel pricing Microsoft Sentinel customer stories Microsoft Sentinel documentationApp Assure’s promise: Migrate to Sentinel with confidence
In today's evolving cyber-threat landscape, enterprises need the most up-to-date tools for detection, investigation, and response. Cloud-native, AI-driven solutions like Microsoft's Sentinel provide businesses with faster implementation, greater integration and automation capabilities, and intelligent event correlation. But when moving from on-prem to the cloud, or from one SIEM to another, migrating can seem risky and complex for Security Operations Centers (SOCs) that have spent years investing in customized solutions. One challenge businesses face is how to port over third-party connectors, especially ones processing large data volumes, which can reach terabytes per day. For customers with such needs, Microsoft has built the Codeless Connector Platform (CCP) in Microsoft Sentinel. Microsoft Sentinel’s Codeless Connector Platform reduces friction for enterprises migrating to the cloud For enterprises ready to modernize their security operations, Microsoft recommends leveraging integrations built on CCP. These integrations are built to handle large data workloads and provide a number of powerful benefits: CCP connectors are a scalable and reliable SaaS offering, capable of handling high-volume data ingestion effortlessly. Its Data Collection Rules (DCRs) enable log filtering and transformation at ingestion, reducing data volume and lowering costs. CCP also streamlines installation and deployment. What formerly took hundreds of lines of code to configure, now takes a few simple mouse clicks. CCP communication is conducted privately between Microsoft services without being exposed to the public internet, thus aligning with Microsoft's security best practices to provide a secure and robust integration environment. What makes CCP an even more compelling and powerful tool is that our App Assure team stands behind the platform to uphold Microsoft’s Sentinel compatibility promise. Microsoft’s Sentinel promise How App Assure delivers on this promise Backed by Microsoft engineering, App Assure is here to help. If a Microsoft Sentinel ISV solution is not yet available or you have an issue with a solution already published by an ISV, App Assure may be able to assist with the following customer scenarios: Working with ISVs to develop new CCP solutions. Working with ISVs to add new features to existing CCP solutions. For supported scenarios, an App Assure Manager will be assigned to guide you through the process, ensuring you can leverage the full power of Sentinel. For customer scenarios that are not supported, App Assure will help you identify available resources. To engage App Assure and learn more about what we support, submit a request for assistance. Partner Testimonials App Assure has already been working with many ISVs on behalf of our customers to fulfil Microsoft’s Sentinel promise. Two recent engagements where we facilitated the integration of tools that our customers rely on include: 1Password Netskope
