Ingesting Windows Security Events into Custom Datalake Tables Without Using Microsoft‑Prefixed Table
Hi everyone, I’m looking to see whether there is a supported method to ingest Windows Security Events into custom Microsoft Sentinel Data Lake–tiered tables (for example, SecurityEvents_CL) without writing to or modifying the Microsoft‑prefixed analytical tables. Essentially, I want to route these events directly into custom tables only, bypassing the default Microsoft‑managed tables entirely. Has anyone implemented this, or is there a recommended approach? Thanks in advance for any guidance. Best Regards, Prabhu Kiran
Add Privacy Scrub Service to Microsoft Defender?
Microsoft Defender protects accounts against phishing and malware, but attackers increasingly exploit nuisance data broker sites that publish personal information (names, emails, addresses). These sites are scraped to personalize phishing campaigns, making them harder to detect. I propose a premium Defender add‑on that automatically files opt‑out requests with major data brokers (similar to DeleteMe).
Enterprise Strategy for Secure Agentic AI: From Compliance to Implementation
Imagine an AI system that doesn’t just answer questions but takes action querying your databases, updating records, triggering workflows, even processing refunds without human intervention. That’s Agentic AI and it’s here. But with great power comes great responsibility. This autonomy introduces new attack surfaces and regulatory obligations. The Model Context Protocol (MCP) Server the gateway between your AI agent and critical systems becomes your Tier-0 control point. If it fails, the blast radius is enormous. This is the story of how enterprises can secure Agentic AI, stay compliant and implement Zero Trust architectures using Azure AI Foundry. Think of it as a roadmap a journey with three milestones - Milestone 1: Securing the Foundation Our journey starts with understanding the paradigm shift. Traditional AI with RAG (Retrieval-Augmented Generation) is like a librarian: It retrieves pre-indexed data. It summarizes information. It never changes the books or places orders. Security here is simple: protect the index, validate queries, prevent data leaks. But Agentic AI? It’s a staffer with system access. It can: Execute tools and business logic autonomously. Chain operations: read → analyze → write → notify. Modify data and trigger workflows. Bottom line: RAG is a “smart librarian.” Agentic AI is a “staffer with system access.” Treat the security model accordingly. And that means new risks: unauthorized access, privilege escalation, financial impact, data corruption. So what’s the defense? Ten critical security controls your first line of protection: Here’s what a production‑grade, Zero Trust MCP gateway needs. Its intentionally simplified in the demo (e.g., no auth) to highlight where you must harden in production. (https://github.com/davisanc/ai-foundry-mcp-gateway) Authentication Demo: None Prod: Microsoft Entra ID, JWT validation, Managed Identity, automatic credential rotation Authorization & RBAC Demo: None Prod: Tool‑level RBAC via Entra; least privilege; explicit allow‑lists per agent/capability Input Validation Demo: Basic (ext whitelist, 10MB, filename sanitize) Prod: JSON Schema validation, injection guards (SQL/command), business‑rule checks Rate Limiting Demo: None Prod: Multi‑tier (per‑agent, per‑tool, global), adaptive throttling, backoff Audit Logging Demo: Console → App Service logs Prod: Structured logs w/ correlation IDs, compliance metadata, PII redaction Session Management Demo: In‑memory UUID sessions Prod: Encrypted distributed storage (Redis/Cosmos DB), tenant isolation, expirations File Upload Security Demo: Ext whitelist, size limits, memory‑only Prod: 7‑layer defense (validate, MIME, malware scanning via Defender for Storage), encryption at rest, signed URLs Network Security Demo: Public App Service + HTTPS Prod: Private Endpoints, VNet integration, NSGs, Azure Firewall no public exposure Secrets Management Demo: App Service env vars (not in code) Prod: Azure Key Vault + Managed Identity, rotation, access audit Observability & Threat Detection (5‑Layer Stack) Layer 1: Application Insights (requests, dependencies, custom security events) Layer 2: Azure AI Content Safety (harmful content, jailbreaks) Layer 3: Microsoft Defender for AI (prompt injection incl. ASCII smuggling, credential theft, anomalous tool usage) Layer 4: Microsoft Purview for AI (PII/PHI classification, DLP on outputs, lineage, policy) Layer 5: Microsoft Sentinel (SIEM correlation, custom rules, automated response) Note: Azure AI Content Safety is built into Azure AI Foundry for real‑time filtering on both prompts and completions. Picture this as an airport security model: multiple checkpoints, each catching what the previous missed. That’s defense-in-depth. Zero Trust in Practice ~ A Day in the Life of a Prompt Every agent request passes through 8 sequential checkpoints, mapped to MITRE ATLAS tactics/mitigations (e.g., AML.M0011 Input Validation, AML.M0004 Output Filtering, AML.M0015 Adversarial Input Detection). The design goal is defense‑in‑depth: multiple independent controls, different detection signals, and layered failure modes. Checkpoints 1‑7: Enforcement (deny/contain before business systems) Checkpoint 8: Monitoring (detect/respond, hunt, learn, harden) AML.M0009 – Control Access to ML Models AML.M0011 – Validate ML Model Inputs AML.M0000 – Limit ML Model Availability AML.M0014 – ML Artifact Logging AML.M0004 – Output Filtering AML.M0015 – Adversarial Input Detection If one control slips, the others still stand. Resilience is the product of layers. Milestone 2: Navigating Compliance Next stop: regulatory readiness. The EU AI Act is the world’s first comprehensive AI law. If your AI system operates in or impacts the EU market, compliance isn’t optional, it’s mandatory. Agentic AI often falls under high-risk classification. That means: Risk management systems. Technical documentation. Logging and traceability. Transparency and human oversight. Fail to comply? Fines up to €30M or 6% of global turnover. Azure helps you meet these obligations: Entra ID for identity and RBAC. Purview for data classification and DLP. Defender for AI for prompt injection detection. Content Safety for harmful content filtering. Sentinel for SIEM correlation and incident response. And this isn’t just about today. Future regulations are coming US AI Executive Orders, UK AI Roadmap, ISO/IEC 42001 standards. The trend is clear: transparency, explainability, and continuous monitoring will be universal. Milestone 3: Implementation Deep-Dive Now, the hands-on part. How do you build this strategy into reality? Step 1: Entra ID Authentication Register your MCP app in Entra ID. Configure OAuth2 and JWT validation. Enable Managed Identity for downstream resources. Step 2: Apply the 10 Controls RBAC: Tool-level access checks. Validation: JSON schema + injection prevention. Rate Limiting: Express middleware or Azure API Management. Audit Logging: Structured logs with correlation IDs. Session Mgmt: Redis with encryption. File Security: MIME checks + Defender for Storage. Network: Private Endpoints + VNet. Secrets: Azure Key Vault. Observability: App Insights + Defender for AI + Purview + Sentinel. Step 3: Secure CI/CD Pipelines Embed compliance checks in Azure DevOps: Pre-build: Secret scanning. Build: RBAC & validation tests. Deploy: Managed Identity for service connections. Post-deploy: Compliance scans via Azure Policy. Step 4: Build the 5-Layer Observability Stack App Insights → Telemetry. Content Safety → Harmful content detection. Defender for AI → Prompt injection monitoring. Purview → PII/PHI classification and lineage. Sentinel → SIEM correlation and automated response. The Destination: A Secure, Compliant Future By now, you’ve seen the full roadmap: Secure the foundation with Zero Trust and layered controls. Navigate compliance with EU AI Act and prepare for global regulations. Implement the strategy using Azure-native tools and CI/CD best practices. Because in the world of Agentic AI, security isn’t optional, compliance isn’t negotiable, and observability is your lifeline. Resources https://learn.microsoft.com/en-us/azure/ai-foundry/what-is-azure-ai-foundry https://learn.microsoft.com/en-us/azure/defender-for-cloud/ai-threat-protection https://learn.microsoft.com/en-us/purview/ai-microsoft-purview https://atlas.mitre.org/ https://digital-strategy.ec.europa.eu/en/policies/european-approach-artificial-intelligence https://techcommunity.microsoft.com/blog/microsoft-security-blog/microsoft-sentinel-mcp-server---generally-available-with-exciting-new-capabiliti/4470125
Question malware detected Defender for Windows 10
Why did my Microsoft Defender detect a malicious file in AppData\Roaming\Secure\QtWebKit4.dll (Trojan:Win32/Wacatac.C!ml) during a full scan and the Kaspersky Free and Malwarebytes Free scans didn't detect it? Was it maliciously modifying, corrupting, or deleting various files on my PC before detection? I sent it to Virus Total, the hash: 935cd9070679168cfcea6aea40d68294ae5f44c551cee971e69dc32f0d7ce14b Inside the same folder as this DLL, there's another folder with a suspicious file, Caller.exe. I sent it to Virus Total, and only one detection from 72 antivirus programs was found, with the name TrojanPSW.Rhadamanthys. VT hash: d2251490ca5bd67e63ea52a65bbff8823f2012f417ad0bd073366c02aa0b3828Quarantine "finger print matching" false positive
Just done my regular quarantine check on our O365 tenant and was surprised to find a couple of legit messages from an external sender which were flagged as High Confidence Phish based on finger print matching, which I understand translates to a close match to a previously detected malicious message. I can see absolutely nothing wrong with the message and it was so very business specific in its content that I cannot see that it would closely match anything else that had ever gone before. The recipient tells me they regularly exchange business emails with the sender without any issue. When I run off a report and look at other recent messages caught by finger print matching on my tenant, they were the usual phishing emails that are probably doing the rounds globally and were correctly trapped. Questions are: 1. Anyone know why something so highly specific in its content would be trapped in this way? 2. I feel I can't trust O365 to correctly quarantine based on this example, but High Confidence Phish is currently set to have the AdminOnlyAccessPolicy applied on my tenant - and this doesn't notify. Is there any way for a sys admin (only) to be notified by email when something goes into quarantine? I can set up a custom policy to allow RECIPIENT notification but I don't really want to involve them when messages are being correctly quarantined almost all of the time. Ours is a non-profit tenant so I can't be sitting around watching it all day - I need it to tell me when something has happened! Thanks for any ideas!Meet Your New Cybersecurity Sidekick - Microsoft Security Copilot Agents
Imagine if your security team had a super-smart assistant that never sleeps, learns from every task, and helps stop cyber threats before they become disasters. That’s exactly what Microsoft’s new Security Copilot Agents are designed to do. Why Do We Need Them? Cyberattacks are getting sneakier and faster many now use AI to trick people or break into systems. In fact, 67% of phishing attacks in 2024 used AI. Meanwhile, security teams are drowning in alerts 66 per day on average and 73% of experts admit they’ve missed important ones. That’s where Security Copilot comes in. It’s like having an AI-powered teammate that helps you investigate threats, fix issues, and stay ahead of attackers. What Are Security Copilot Agents? Think of these agents as mini digital coworkers. They’re not just chatbots they’re smart, adaptable tools that: Learn from your feedback Work with your existing Microsoft security tools Help you make faster, better decisions Keep you in control while they handle the heavy lifting They’re built to be flexible and smart unlike traditional automation that breaks when things change. Real-World Examples of What They Do Here are a few of the agents already available: Phishing Triage Agent: Automatically checks if a suspicious email is a real threat or just spam. It explains its reasoning in plain language and learns from your feedback. Alert Triage Agents (in Microsoft Purview): Helps prioritize which security alerts matter most, so your team can focus on the big stuff first. Conditional Access Optimization Agent (in Microsoft Entra): Keeps an eye on who has access to what and flags any gaps in your security policies. Vulnerability Remediation Agent (in Microsoft Intune): Spots the most urgent software vulnerabilities and tells you what to fix first. Threat Intelligence Briefing Agent: Gives you a quick, customized report on the latest threats that could affect your organization. Even More Help from Partners Microsoft is also teaming up with other companies to build even more agents. For example: OneTrust helps with privacy breach responses. Tanium helps analysts make faster decisions on alerts. Fletch helps reduce alert fatigue by showing what’s most important. Aviatrix helps diagnose network issues like VPN or gateway failures. BlueVoyant: helps to assess your SOC and recommends improvements. Why It Matters These agents don’t just save time they help your team stay ahead of threats, reduce stress, and focus on what really matters. They’re like having a team of AI-powered interns who never get tired and are always learning. Learn More 📢 Microsoft Security Blog: Security Copilot Agents Launch 🎥 https://aka.ms/SecurityCopilotAgentsVideo
Extremely Slow Performance Since Defender Was Pushed on Us
Compliance, Security, Protection, and Defender are all extremely slow, with responses from screen to screen ranging from 30 seconds to multiple minutes between clicking items and waiting for Microsoft cloud to return results. I have a GB link and speed test well over 600 Mbps so it's not on my end. It appears the cutover in late January to this new "Defender" platform has been extremely detrimental to the Office portal response times in these portals. What is being done to resolve this?
User app registration - exploitable for BEC?
Hello. Recently dealt with a case of BEC. I'm not trained in forensics, but doing my best. Appears the hacker used an application called eM Client for their attack, getting access to a user's mailbox and hijacking a thread. I can see the login from two weeks ago (the incident was only noticed a couple days ago, however) - from a European country that SHOULD have been blocked by Conditional Access. Come to find out, the tenant conditional access was unassigned from everyone. We're not sure how - we re-enabled it, and audited changes, but the only change that appears was us re-enabling it. Which I thought indicates it was never configured right, except we've got a ticket documenting a change to Conditional Access a couple days after the hack that ALSO does not appear in the logs. So... it's likely it was changed, yet I have no record of that change (atleast, not through Entra > Monitoring > Auditing). If anyone knows any other ways of checking this, please advise - but I can't seem to even access our Diagnostic settings, the page tells me I need an Azure Active Directory subscription (I'm on Entra ID P1, which includes AAD.... this might be related to being global admin, and not Security Admin - we don't use that role in this relationship) ANYWAY, my amateur forensic skills have found that the attacker used an app called eM Client to get access. I'm not sure yet how they obtained the password, and got past MFA... But quick research shows this application (esp it's pro version) is known for use in BEC. The app was registered in Entra, and granted certain read permissions in Entra ID for shared mailboxes, presumably to find a decent thread to hijack. I'm not 100% sure yet there was any actual exploit done using this app, but it's popularity amongst hackers implies it does SOMETHING useful (i think remember that it authenticates using Exchange Web Services instead of Exchange Online, or something similar? Will update when I have the chance to check). We're in the process of improving our Secure Score, and this incident makes me think user's ability to register apps should be locked down. Checked Secure Score for this, and while there ARE recommendations around apps, disabling user app registration is NOT one of them. Just curious about people's thoughts. I just barely understand App Registration in Entra, but if this is a known attack vector, I would think disabling app registration would be a security recommendation?
