Using the Microsoft Defender for Endpoint Files API to Validate Malware Hashes
Introduction Security advisories frequently include file hashes (SHA-1 or SHA-256) as indicators of compromise (IoCs). Microsoft Defender for Endpoint (MDE) exposes a Files API that lets SecOps quickly look up Microsoft’s verdict and metadata for a given hash. This enables rapid assessment—whether a file is classified as Malicious, Suspicious, Clean, or Unknown—and helps analysts decide the next response action without needing to download or execute the sample. What is the Files API in MDE and why is it used in Security Operations? The Files API is part of the Defender for Endpoint REST APIs that returns a file profile by hash identifier. Analysts use it to: • Validate whether Microsoft has a global verdict for a hash named in an advisory. • Retrieve telemetry such as global prevalence and first/last observed times to gauge risk and spread. • Pivot to related alerts and devices when needed. This lookup shortens triage time and avoids unnecessary handling of potentially dangerous samples. Prerequisites To call the Files API using application (client credentials) context, you need: A Microsoft Entra ID App Registration (Web app / service). API permissions on the WindowsDefenderATP resource (Microsoft Defender for Endpoint). Minimum: File.Read.All (Application). Admin consent granted for the permissions. Network access to the MDE API endpoint (region-based base URL) and the Microsoft identity platform (OAuth 2.0). Tip: For interactive testing, you can also use the API Explorer in the Microsoft Defender portal under Partners & APIs, which runs requests under your user context and RBAC scope. How to use the Files API via PowerShell 1) Acquire an OAuth token from the Microsoft identity platform using your app’s client ID and secret with the .default scope for the Defender API. 2) Send an HTTP GET request to the Files endpoint with the hash (SHA-1 or SHA-256) as the identifier. 3) Inspect the JSON response field "fileClassification" and other metadata (globalPrevalence, first/last observed). 4) Use the verdict to decide next actions (e.g., create an Indicator to block, hunt in Advanced Hunting, or open related alerts). Actual Script ===== STEP 1: Get OAuth Token (MDE v1) ===== $tenantId = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" $appId = "xxxxxxxxxxxxxxxxxxxxxxxxxxx" $appSecret = "xxxxxxxxxxxxxxxxxxxxxxxxxxx" # update with your tenant and app values $tokenUri = "https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token" $body = @{ client_id = $appId scope = "https://api.securitycenter.microsoft.com/.default" client_secret = $appSecret grant_type = "client_credentials" } $tokenResponse = Invoke-RestMethod -Uri $tokenUri -Method Post -Body $body -ContentType "application/x-www-form-urlencoded" $token = $tokenResponse.access_token # ===== STEP 2: Call MDE v1 Files API ===== $hash = "97bf5e1a903a978b2281496e0a897688e9d8e6f981238cf91e39bae20390defe" # Replace with your actual hash values. $uri = "https://api.securitycenter.microsoft.com/api/v1.0/files/$hash" try { $response = Invoke-RestMethod -Uri $uri -Headers @{ Authorization = "Bearer $token" Accept = "application/json" } -Method Get } catch { Write-Error "API call failed: $($_.Exception.Message)" if ($_.ErrorDetails.Message) { Write-Host $_.ErrorDetails.Message } return } switch ($response.fileClassification) { "Malicious" { Write-Host "MDE recognises this hash as MALICIOUS. Threat Name: $($response.threatName)" -ForegroundColor Red } "Suspicious" { Write-Host "MDE recognises this hash as SUSPICIOUS." -ForegroundColor Yellow } "Clean" { Write-Host "MDE recognises this hash as CLEAN." -ForegroundColor Green } default { Write-Host "MDE does NOT have a signature for this hash (Unknown)." -ForegroundColor Gray } } $response | ConvertTo-Json -Depth 5 Script Explanation Token acquisition: Uses OAuth 2.0 client credentials flow to obtain an access token; scope targets Defender for Endpoint API. Endpoint call: Builds a GET request to the Files endpoint with the hash identifier. Error handling: Catches HTTP errors and prints server-provided details if available. Verdict mapping: Reads the fileClassification field and prints a color-coded verdict (Malicious, Suspicious, Clean, Unknown). Response output: Prints the full JSON for deeper analysis and logging. Recommended Inputs The Files endpoint accepts SHA-1 or SHA-256 identifiers; ensure you pass the correct hash type. Consider using certificate credentials or managed identity instead of client secrets for production automation. Sample Output API Explorer - Other Option to query File API The Microsoft Defender for Endpoint API Explorer is a tool that helps you explore various Defender for Endpoint APIs interactively. The API Explorer makes it easy to construct and do API queries, test, and send requests for any available Defender for Endpoint API endpoint. Use the API Explorer to take actions or find data that might not yet be available through the user interface. The tool is useful during app development. It allows you to perform API queries that respect your user access settings, reducing the need to generate access tokens. You can also use the tool to explore the gallery of sample queries, copy result code samples, and generate debug information. With the API Explorer, you can: Run requests for any method and see responses in real-time. Quickly browse through the API samples and learn what parameters they support. Make API calls with ease; no need to authenticate beyond the management portal signin. Access API Explorer From the left navigation menu, select Partners & APIs > API Explorer. Supported APIs API Explorer supports all the APIs offered by Defender for Endpoint. The list of supported APIs is available in the APIs documentation. Get started with the API Explorer In the left pane, there's a list of sample requests that you can use. Follow the links and click Run query. Some of the samples may require specifying a parameter in the URL, for example, {File Hash}. Permissions Required You need to log in with an account that has appropriate RBAC roles in Microsoft Defender for Endpoint. API Explorer enforces the same role-based access control (RBAC) as the portal: Security Administrator or Global Administrator for high-privilege actions (e.g., offboarding a device, submitting indicators). Lower roles (e.g., Security Reader) can only run read-only queries like Get file information or Get alerts. No additional API permissions or app registration are needed because requests run under your user context. Conclusion The MDE Files API gives SecOps an immediate way to validate hashes from advisories and threat feeds, reducing time-to-triage and enabling consistent response. When a hash is classified as Malicious or Suspicious, teams can move directly to containment (e.g., creating an Indicator to block). When it is Clean or Unknown, analysts can pivot to hunting, sandboxing, or further intelligence before acting. Integrating this lookup into runbooks helps security operations quickly and safely respond to emerging threats. References Get file information API: https://learn.microsoft.com/en-us/defender-endpoint/api/get-file-information Supported MDE APIs (Endpoint URI & versioning): https://learn.microsoft.com/en-us/defender-endpoint/api/exposed-apis-list Access the Microsoft Defender for Endpoint APIs (intro & app context): https://learn.microsoft.com/en-us/defender-endpoint/api/apis-intro Create an app to access MDE without a user (app registration & permissions): https://learn.microsoft.com/en-us/defender-endpoint/api/exposed-apis-create-app-webapp API Explorer: https://learn.microsoft.com/en-us/defender-endpoint/api/api-explorer
MS Purview Data Map - Sensitivity Label - Atlas API
Hi Everyone, Can someone confirm if it’s possible to update the Sensitivity label column in the Microsoft Purview Unified Data Catalog using the Atlas API? Since Microsoft Fabric currently does not support the auto-labeling feature in the Data Map, can we apply sensitivity labels to Fabric assets in the catalog through the Atlas API? Regards, BanuMuraliPreview: Govern, Secure, and Observe A2A APIs with Azure API Management
Today, we’re announcing the preview support for A2A (Agent2Agent) APIs in Azure API Management. With this capability, organizations can now manage and govern agent APIs alongside AI model APIs, Model Context Protocol (MCP) tools, and traditional APIs such as REST, SOAP, GraphQL, WebSocket, and gRPC — all within a single, consistent API management plane. Extending API Governance into the Agentic Ecosystem As organizations adopt agentic systems, the need for consistent governance, security, and observability grows. With A2A API support, Azure API Management enables you to extend established API practices into the agentic world — ensuring secure access, consistent policy enforcement, and complete visibility for AI agents. A2A APIs in Azure API Management: Mediate JSON-RPC runtime operations with policy support Expose and manage agent cards for users, clients, or other agents Support OpenTelemetry GenAI semantic conventions when logging traces to Application Insights — including "gen_ai.agent.id" and "gen_ai.agent.name" attributes How It Works When you import an A2A API, API Management mediates runtime calls to your agent backend (JSON-RPC only) and exposes the agent card as an operation within the same API. The agent card is transformed automatically to represent the A2A API managed by API Management — with the hostname replaced by API Management’s gateway address, security schemes converted to authentication configured in API Management, and unsupported interfaces removed. When integrated with Application Insights, API Management enriches traces with GenAI-compliant telemetry attributes — allowing easy identification of the agent and deep correlation between API and agent execution traces for monitoring and debugging. Try It Out To import an A2A API: Navigate to the APIs page in the Azure portal and select the A2A Agent tile. Enter your agent card URL. If accessible, the portal will automatically populate relevant settings. Configure the remaining properties, such as API path in API Management. This functionality is currently available only in v2 tiers of API Management and it will continue to roll out to all tiers in the coming months. Start Managing Your Agent APIs With A2A support in Azure API Management, you can now bring agent APIs under the same governance and security umbrella as your existing APIs — strengthening control, security, and observability across your AI and API ecosystems. Learn more about A2A API support in Azure API Management.
O365 Group email settings
I am in the middle of trying to create some automated routines that create groups in O365 and add/remove members from them as needed. One of things I ran into is that when an email is sent to the group, the emails are not going into each members' inbox and are only visible in Outlook through "Go to groups" in the left hand menu. I can see the settings that need to be set but can't set them because either, A: it just doesn't do it or B: says I don't have permission. Doing this through C# and the Graph SDK The two items I think I need to turn on are below. What permissions are needed to be able to manage those settings but NOT be able to have access to anyone and everyones' email boxes, emails, etc or is there another way to do this? IsSubscribedByMail AutoSubscribeNewMembersAI Gateway in Azure API Management Is Now Available in Microsoft Foundry (Preview)
For more than a decade, Azure API Management has been the trusted control plane for API governance, security, and observability on a global scale supporting more than 38,000 customers, almost 3 million APIs, and 3 trillion API requests every month. AI Gateway builds on this foundation, extending API Management’s proven governance, security, and observability model to AI workloads, including models, tools, and agents. Today, more than 1,200 enterprise customers use AI Gateway to safely operationalize AI at scale. As customers accelerate AI adoption, the need for consistent, centralized governance becomes even more critical. AI systems increasingly rely on a mix of models, tools, and agents, each introducing new access patterns and governance requirements. Enterprises need a unified way to ensure all this AI traffic remains secure, compliant, and cost-efficient without slowing down developer productivity. Today, we’re making that significantly easier. AI Gateway is now integrated directly into Microsoft Foundry. This gives Foundry users a simple way to govern, observe, and secure their AI workloads with the same reliability and trust as Azure API Management. This integration brings enterprise-grade AI governance directly into Microsoft Foundry right where teams design, build, and operate their AI applications and agents. It provides a streamlined experience that helps organizations adopt strong governance from day one while keeping full API Management capabilities available for advanced configuration. Governance for models With this integration, customers can create a new AI Gateway instance (powered by API Management Basic v2) or associate an existing API Management resource into their Foundry resource. Once configured, all model deployments in the Foundry resource can be accessed through the AI Gateway hostname, ensuring that calls to models, whether to Azure OpenAI or other models, flow through consistent governance and usage controls. Long-term token quotas and short-term token limits can be managed directly within the Foundry interface, enabling teams to set and adjust usage boundaries without leaving the environment where they build and deploy AI applications and agents. Learn more here. Governance for agents The integration also introduces a unified way to govern agents. Organizations can register agents running anywhere — in Azure, other clouds, or on-premises — into the Foundry Control Plane. These agents appear alongside Foundry-native agents for centralized inventory, monitoring, and governance. Teams can view telemetry collected by AI Gateway directly in Foundry or in Application Insights without any reconfiguration of agents at source. Administrators can block agents posing security, compliance, or cost risks within Foundry or apply advanced governance policies, like throttling or content safety, in Azure API Management. Learn more here. Governance for tools Tools benefit from the same consistent governance model. Foundry users can register Model Context Protocol (MCP) tools hosted across any environment and have them automatically governed through the integrated AI Gateway. These tools appear in the Foundry inventory, making them discoverable to developers and ready for consumption by agents. This reduces the operational overhead of securing and mediating tools, simplifying the path to building agentic applications that safely interact with enterprise systems. Learn more here. Unified governance across Foundry and API Management Together, these capabilities bring the power of AI Gateway directly into Microsoft Foundry removing barriers to adoption while strengthening governance. The experience is streamlined with simple setup, intuitive controls, and immediate value. At the same time, customers retain full access to the breadth and depth of API Management capabilities. When advanced policies, enterprise networking, federated gateways, or fine-grained controls are required, teams can seamlessly shift into the API Management experience without losing continuity. With AI Gateway now part of Microsoft Foundry, teams can build and scale AI applications with confidence knowing that consistent governance, security, and observability are built in from the start. AI Gateway in Microsoft Foundry gives every organization a consistent way to govern AI - models, tools, and agents - with the reliability of API Management and the velocity of Foundry. Getting started To set up and use AI Gateway in Foundry, follow the steps in this article. A new AI Gateway deploys an API Management Basic v2 instance for free for the first 100,000 calls. Explore these new capabilities in depth at Microsoft Ignite. Join the Azure API Management and Microsoft Foundry sessions. If attending the conference in person try the hands-on labs to experience how AI Gateway and Foundry help deliver secure and scalable AI applications and stop by our booths to meet the product teams behind these innovations. Session Speaker(s) Link BRK1706: Innovation Session: Build & Manage AI Apps with Your Agent Factory Yina Arenas, Sarah Bird, Amanda Silver, Marco Casalaina https://ignite.microsoft.com/en-US/sessions/BRK1706?source=sessions BRK113: Upskill AI agents with the Azure app platform Mike Hulme, Balan Subramanian, Shawn Henry https://ignite.microsoft.com/en-US/sessions/BRK113?source=sessions BRK119: Don’t let your AI agents go rogue, secure with Azure API management Anish Tallapureddy, Mike Budzynski https://ignite.microsoft.com/en-US/sessions/BRK119?source=sessions LAB519: Governing AI Apps & Agents with AI Gateway in Azure API Management Annaji sharma Ganti, Galin Iliev https://ignite.microsoft.com/en-US/sessions/LAB519?source=sessions
Cannot update Case number in Microsoft Purview eDiscovery
I can no longer update the Case number under case settings in the new eDiscovery UI. I used to be able to update it via the externalId Graph endpoint but that appears to be deprecated. The error simply reads "update failed" - there is no additional information. Is anyone else having this problem?
Entra Conditional Access Issue
Hi Guys, Our Outlook add-in relies on the Graph API to fetch emails. Due to customer-side Conditional Access (CA) Policies, we are seeing critical failures where Continuous Access Evaluation (CAE) demands user interaction (InteractionRequired code) to resolve challenges like LocationConditionEvaluationSatisfied or TokenCreatedWithOutdatedPolicies. Since this authentication occurs backend-to-Entra, we lack a frontend mechanism to prompt the required user interaction. Is there a recommended pattern, method, or architectural change that allows our backend to redirect or challenge the user for interactive sign-in, thereby satisfying these CAE requirements and unblocking customers? Exact error messages: 1. Continuous access evaluation resulted in challenge with result: InteractionRequired and code: LocationConditionEvaluationSatisfied 2. Continuous access evaluation resulted in challenge with result: InteractionRequired and code: TokenCreatedWithOutdatedPoliciesIntroducing native Service Bus message publishing from Azure API Management (Preview)
We’re excited to announce a preview capability in Azure API Management (APIM) — you can now send messages directly to Azure Service Bus from your APIs using a built-in policy. This enhancement, currently in public preview, simplifies how you connect your API layer with event-driven and asynchronous systems, helping you build more scalable, resilient, and loosely coupled architectures across your enterprise. Why this matters? Modern applications increasingly rely on asynchronous communication and event-driven designs. With this new integration: Any API hosted in API Management can publish to Service Bus — no SDKs, custom code, or middleware required. Partners, clients, and IoT devices can send data through standard HTTP calls, even if they don’t support AMQP natively. You stay in full control with authentication, throttling, and logging managed centrally in API Management. Your systems scale more smoothly by decoupling front-end requests from backend processing. How it works The new send-service-bus-message policy allows API Management to forward payloads from API calls directly into Service Bus queues or topics. High-level flow A client sends a standard HTTP request to your API endpoint in API Management. The policy executes and sends the payload as a message to Service Bus. Downstream consumers such as Logic Apps, Azure Functions, or microservices process those messages asynchronously. All configurations happen in API Management — no code changes or new infrastructure are required. Getting started You can try it out in minutes: Set up a Service Bus namespace and create a queue or topic. Enable a managed identity (system-assigned or user-assigned) on your API Management instance. Grant the identity the “Service Bus data sender” role in Azure RBAC, scoped to your queue/ topic. Add the policy to your API operation: <send-service-bus-message queue-name="orders"> <payload>@(context.Request.Body.As<string>())</payload> </send-service-bus-message> Once saved, each API call publishes its payload to the Service Bus queue or topic. 📖 Learn more. Common use cases This capability makes it easy to integrate your APIs into event-driven workflows: Order processing – Queue incoming orders for fulfillment or billing. Event notifications – Trigger internal workflows across multiple applications. Telemetry ingestion – Forward IoT or mobile app data to Service Bus for analytics. Partner integrations – Offer REST-based endpoints for external systems while maintaining policy-based control. Each of these scenarios benefits from simplified integration, centralized governance, and improved reliability. Secure and governed by design The integration uses managed identities for secure communication between API Management and Service Bus — no secrets required. You can further apply enterprise-grade controls: Enforce rate limits, quotas, and authorization through APIM policies. Gain API-level logging and tracing for each message sent. Use Service Bus metrics to monitor downstream processing. Together, these tools help you maintain a consistent security posture across your APIs and messaging layer. Build modern, event-driven architectures With this feature, API Management can serve as a bridge to your event-driven backbone. Start small by queuing a single API’s workload, or extend to enterprise-wide event distribution using topics and subscriptions. You’ll reduce architectural complexity while enabling more flexible, scalable, and decoupled application patterns. Learn more: Get the full walkthrough and examples in the documentation 👉 here
403 Error: Application access policy not found, -Global scope not available in tenant
Hi everyone, I'm trying to use Microsoft Graph API to retrieve online meeting details using an application identity. However, I receive a 403 error with the message: "No application access policy found for this app" I followed the documentation here: Configure application access policy, but I encountered a problem: the -Global scope mentioned in the documentation is not available in my tenant. I’ve successfully granted the policy using the following methods: Option A – Grant to Specific User Grant-CsApplicationAccessPolicy -PolicyName "YOUR_POLICY_NAME" -Identity "email address removed for privacy reasons" Option B – Grant to AD Group New-CsGroupPolicyAssignment -GroupId "YOUR_GROUP_ID" -PolicyType ApplicationAccessPolicy -PolicyName "YOUR_POLICY_NAME" These work fine, and the app can access online meetings for users or groups assigned this way. However, I need to allow the app to access meetings across the organization, and the -Global assignment method is not available in my tenant. Questions: Is there an alternative to -Global for tenant-wide access? Is this limitation expected in certain tenant configurations? Any workaround or best practice for enabling organization-wide access to online meetings via Graph API? Thanks in advance!
