M365 Show Podcast

Mirko Peters

Welcome to the M365 Show — your essential podcast for everything Microsoft 365, Azure, and beyond. Join us as we explore the latest developments across Power BI, Power Platform, Microsoft Teams, Viva, Fabric, Purview, Security, and the entire Microsoft ecosystem. Each episode delivers expert insights, real-world use cases, best practices, and interviews with industry leaders to help you stay ahead in the fast-moving world of cloud, collaboration, and data innovation. Whether you're an IT professional, business leader, developer, or data enthusiast, the M365 Show brings the knowledge, trends, and strategies you need to thrive in the modern digital workplace. Tune in, level up, and make the most of everything Microsoft has to offer. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support.

  1. Why Your Threat Analytics Is Useless (The Report You Missed)

    HÁ 10 H

    Why Your Threat Analytics Is Useless (The Report You Missed)

    In this episode, we break open one of the most misunderstood security capabilities in Microsoft 365: Threat Analytics. Not the dashboard you scroll past. Not the report you skim. The living, breathing intelligence engine that can slash dwell time, expose hidden attack paths, and transform your SOC from reactive to relentless. Most organizations never use Threat Analytics the way it was designed. They read the headline but skip the MITRE mapping. They see recommendations but never bind them to Secure Score actions or owners. They ignore the tenant-specific exposure panel that quietly says, “This is happening here.” Today, we fix that. 🔥 What This Episode Delivers The hard truth (and the promise) We begin with a call to awareness: Threat Analytics isn’t useless — it’s unused. Attackers walk through doors we should have closed. This episode teaches a single pattern that saves you from that: read → test → act → verify. Not someday. Today. 1. What Threat Analytics really is — and what it’s not You’ll learn how Threat Analytics combines global threat intelligence, Microsoft IR experience, MITRE ATT&CK mapping, tenant-specific exposure, and actionable recommendations into one unified signal. We explore: How to extract techniques and artifactsHow to interpret the exposure panelWhy recommendations are not “ideas,” but enforceable controlsHow Threat Analytics links incidents and Secure Score into one defensive narrativeThis section gives listeners a blueprint for understanding the full value of the feature, not just what appears at the top of the page. 2. The three oversights that make security teams blind We uncover the three habits that turn Threat Analytics into a passive newsletter: Skipping MITRE techniques and exposure dataTreating recommendations as optionalIgnoring device and account evidenceYou’ll learn why these oversights add days to dwell time and how to flip them into strengths with simple structural fixes. 3. The One-Hour Method — turn any report into action This is the heart of the episode: a 60-minute workflow your team can run every week. You’ll learn how to: Select the right reportExtract techniques, TTPs, and artifactsBuild targeted hunting queries in DefenderCorrelate findings to incidentsAssign Secure Score controls with owners and SLAsVerify protections, rerun queries, and document outcomesThis method reduces time-to-detect and closes attack paths with ruthless consistency. 4. Two real detection gaps — and how to close them We walk through two live threat paths that regularly bypass unstructured SOCs: Phishing → OAuth consent abuse → token replayLiving-off-the-land persistence through script interpreters and abused binariesYou’ll hear exactly how to hunt them, which events reveal them, which policies block them, and how Threat Analytics guides the remediation. 5. Measurement and governance that actually prove value Security programs fail without metrics. We show you how to measure what matters: Time-to-detect (TTD)Named attack paths closed by techniqueSecure Score controls enacted from real reportsExposure changes across your tenantYou’ll walk away knowing how to build dashboards that make improvement visible — daily, weekly, monthly. ✨ Why This Episode Is a Must-Listen If you defend Microsoft 365, this episode teaches you how to: Turn global intelligence into tenant-specific actionShorten dwell time using repeatable workflowsImprove Secure Score based on real threatsCommunicate risk and progress to leadershipClose attack paths with evidence, not hopeIt’s practical. It’s repeatable. And it’s framed in a narrative style that makes the lessons unforgettable. 🎧 Listen Now If you’re responsible for M365 security, SOC operations, DFIR, governance, or cloud architecture, this is one of the most actionable episodes you’ll hear all year. Read with intent. Test with precision. Act with ownership. Verify with evidence. This is the covenant in the cloud. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support. Follow us on: LInkedIn Substack

    29min
  2. The M365 Audit Logs You're Ignoring: Why Zero Trust is a Lie Without Them

    HÁ 22 H

    The M365 Audit Logs You're Ignoring: Why Zero Trust is a Lie Without Them

    An account pulled down 12,000 SharePoint files in 20 minutes. No malware, no DLP alert, no blocked session. Zero Trust said “allowed.” In this episode, we dissect why Zero Trust without audit evidence is policy theater—and how to fix it. You’ll learn how to fuse Entra sign-in risk, the Microsoft 365 Unified Audit Log, Purview policy edits, and Copilot interactions into one coherent timeline. We finish by reconstructing a quiet exfiltration case step by step and give you concrete detection recipes, KQL ideas, and automation patterns you can deploy in your own tenant. Opening – The Anomaly Zero Trust Can’t Explain It starts with a warning and ends with silence: One account downloads 12,000 SharePoint files in under 20 minutes. No malware. No DLP alert. Conditional Access says “allowed.” The thesis: Zero Trust without audit evidence is policy theater. Verification isn’t a checkbox; it’s a trail. In this episode, we: Pull from four log sources:Entra ID sign-in & riskMicrosoft 365 Unified Audit Log (UAL)Purview retention & policy changesCopilot interaction logsShow the one log pivot that reliably exposes data stagingReconstruct a real-style exfiltration case, end to endTurn it into queries, alerts, dashboards, and automationSection 1 – Entra ID Sign-in & Risk: Verify the Verifier Every breach still begins with an identity. Entra’s risk signals are your earliest warning—but only if you keep them long enough and correlate them correctly. Key points: Entra splits visibility:Risky sign-ins: ~30-day windowRisk detections: often ~90 daysIf you only review risky sign-ins, you lose early signals and can’t reconstruct the path later.Three streams you must track together: Risky sign-ins – the attempts and outcomesRisk detections – patterns like anomalous token or AiTMWorkload identity anomalies – service principals behaving like usersHigh-priority detections: Anomalous token → session theft / replayAttacker-in-the-middle → sign-in through a malicious proxyUnfamiliar sign-in properties → new device / client / IP combosThe catch: Conditional Access can “succeed” while the threat remains.Medium-risk sign-in → prompt for MFA → success → session allowed.Repeated medium risk over days correlates strongly with later data staging.What to actually do: Join sign-ins with Conditional Access evaluation so every successful auth carries:UserId, AppId, IP, DeviceId, derived SessionIdRiskDetail, RiskLevel at event timeWhich CA policy allowed / challenged itPatterns to alert on: Repeated medium-risk sign-ins:3+ in 7 days from distinct ASNs / IP ranges → investigation, not “business as usual”Workload identities suddenly authenticating from public IPs or gaining new API permissionsIf risk >= high and token anomalies present → force sign-out and require password resetRetention hygiene: Export risky sign-ins weekly beyond the 30-day window.Keep risk detections in your SIEM for 180 days+ so you can replay the first 12 hours when it matters.Bottom line: verify the verifier. The sign-in narrative is the prologue. The story starts when movement begins. Section 2 – Unified Audit Log: Trace Lateral Movement Across Workloads Once the door opens, the Unified Audit Log is your ledger. It captures cross-service movement: Exchange, SharePoint, OneDrive, Teams, and admin actions in one place.Why it matters: Real attackers don’t stay in one workload. They:Add mailbox forwarding rulesChange SharePoint permissionsRegister new sync clientsCreate sharing links that bypass normal pathsThree lenses to apply to the UAL: Identity lens – UserId, AppId, ClientIP, SessionKeyPrivilege lens – mailbox permissions, site admin changes, role assignmentsData lens – FileDownloaded, FileAccessed, FileSyncAdded, SharingLinkCreatedCore idea: Privilege change + data surge = staging, not collaboration. Better than raw “mass download”: Build per-user baselines and look for change from baseline:User normally touches ~20 files per daySuddenly touches 800 unique items across two sites in 30 minutesPlus: new sync relationship and wider sharing links → staging, not syncKill chain reconstruction uses patterns like: Set-InboxRule or Set-Mailbox forwarding externallyFollowed by a burst of SharePoint FileDownloaded in that same sessionPlus SharingLinkCreated with “Anyone” or “Organization” scopePractical moves: Stream UAL via the Management Activity API into Sentinel/Log AnalyticsNormalize by: UserId, ClientIP, Operation, ObjectId, RecordType, TimestampBuild session keys (User + IP + App + 30–45 min bin) and aggregate:UniqueFiles, UniqueSites, privilege-change flags, sharing-scope changes Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support. Follow us on: LInkedIn Substack

    41min
  3. Why Your M365 Security Fails Against Social Engineering

    HÁ 1 DIA

    Why Your M365 Security Fails Against Social Engineering

    Attention, valued knowledge workers. By order of the Productivity Council, your Microsoft 365 defenses are failing precisely where human judgment collides with ambiguous policy. Many assume MFA, EDR, and secure score form an adequate perimeter. They do not. They do not arrest consent exploitation, device-code laundering, or Teams pretexting executed under your own brand. Here is the operational truth: adversaries enter through official channels and harvest trust at line speed. The Council will present five incident case files and the corrective doctrine—policies, detections, user protocols, and tooling. One misconfiguration currently nullifies your MFA entirely. Remember it. Its name will be issued shortly. Citizens, this is the formal record of Authority Theater. The adversary enters not through malware nor brute force, but through Teams external federation—the front door you assumed was screened. A profile appears: “IT Support – Priority”. Microsoft-colored avatar. Crisp timing. The message asserts a routine authentication irregularity and promises expedited resolution. A verification number follows. Familiar. Harmless-looking. The intended mechanism is approval fatigue. The victim, already conditioned by countless legitimate prompts, approves the MFA request to “resolve the issue.” In that instant, an attacker-in-the-middle relay kit captures the session token. The mailbox changes. The SharePoint site syncs. Teams threads flicker with unseen edits. Compliance evaporates silently. Failure Analysis This breach does not demonstrate adversary brilliance—it reveals policy ambiguity. External access defaults remain permissive. Most tenants allow any federated domain to message any user.Message hygiene is not enforced. Unsolicited DMs from new tenants are not quarantined or rate-limited.Risk policies operate independently of collaboration channels. A risky session triggered from a Teams-initiated elevation looks “normal” to identity systems.Verification protocol does not exist. Users cannot distinguish a sanctioned IT outreach from an adversarial pretext.This is not failure of technology; it is failure of ceremony. Corrective Doctrine The following orders are mandatory: 1. Restrict External Federation Disable Teams external federation entirely, or narrow it to an explicit allow list of partner domains. In Teams Admin Center: External access → Deny by default.Add only verified partner tenants. Use shared channels for legitimate collaboration; forbid unsolicited tenant-to-tenant DMs.Enable Safe Links for Teams with real-time detonation to scrub URLs before delivery. 2. Treat Teams as an Elevation Vector Teams is an identity elevator and must be governed as such. Conditional Access requirements: Require compliant device for any Teams-initiated access to Exchange, SharePoint, or admin portals.Enforce phishing-resistant authentication strengths (FIDO2, CBA) for privileged workloads.For risky sign-ins: restrict to web-only, block download, and require reauthentication before sensitive operations.Shorten sign-in frequency for elevated roles—durable exposure is unacceptable.3. Detection: The But/Therefore Chain Detection must acknowledge the causal pattern: A message appears →therefore an MFA prompt follows →therefore elevation is attempted.Correlate: Inbound external DMs from unseen tenantsMFA prompt clusters in five-minute windowsDevice context mismatches (consumer IP → corporate elevation)Sudden mailbox or SharePoint privilege activitySIEM must ingest these as a single incident chain, not discrete noise. 4. User Protocol: Verification Rituals Training is procedural, not optional. Verification Phrase Protocol: All legitimate IT outreach includes a rotating phrase listed on the intranet. No phrase, no action.Code-over-Voice Prohibition: Citizens are forbidden to read codes, numbers, device codes, or MFA digits into chat, SMS, or voicemail. Ever.Mandatory Pause Rule: Stop. Verify using the Service Desk number printed on the badge—not the number in the message. Proceed only upon confirmation.5. Instructional Micro-Story 08:12. A finance analyst receives a DM titled “Payroll Lock.” A prompt appears. They decline. They invoke the pause rule. The Service Desk confirms no ticket exists. Security correlates the DM with deviceAuth endpoint hits, blocks access, and revokes tokens. A breach evaporates because a protocol, not improvisation, controlled the moment. 6. Tooling Enforcement Activate: Defender for Office Safe Links in TeamsDefender for Cloud Apps policies for mass external messaging, anomalous OAuth consent seeded from TeamsUEBA baselines for chat frequency, external-tenant ratios, and time-of-day anomaliesSOAR responses that isolate sessions and enforce FIDO2 reauthentication when Teams-to-MFA patterns appearClosing Directive Teams is not a chat room. It is an identity surface. Therefore, supervision is compulsory. If external messaging is not business-critical, disable it. If it is, confine it under governance. When chat pretext fails under verification friction, adversaries pivot. They reach for device code flows, capturing cooperation without asking for a password. Case File II will document that pivot. Mandatory compliance is appreciated. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support. Follow us on: LInkedIn Substack

    44min
  4. Teams Channels Are Not Secure By Default: The Admin Lie

    HÁ 1 DIA

    Teams Channels Are Not Secure By Default: The Admin Lie

    Teams is not secure by default—especially in hybrid environments full of guests, private channels, and synced libraries. In this episode, we walk through two real-world style incidents where “set and forget” Teams defaults quietly exposed data, then build a five-layer hardening plan: Conditional Access that actually bites, Purview DLP on chat and channels, Entra ID guest governance, audit & forensics you can prove in court, and retention that survives scrutiny. You’ll leave with exact policy patterns you can copy, test, and measure in your own tenant. Opening – The Hook & Value Promise The night’s loud with static. Teams channels hum like open vents. Guests linger. Files sync to places no one watches. One careless paste away from a bleed you can’t stop. This episode gives you a concrete Teams security blueprint: Enforce MFA for everyone, including guestsKill legacy authenticationRequire compliant or protected devices for Teams / SharePoint / ExchangeWire Purview DLP into chat and channelsGovern guests with expirations, reviews, and access packagesProve it all in logs, holds, and auditsYou’ll see two incidents that show how defaults burn tenants—and then we’ll build the five layers that would have stopped them. Segment 1 – Incident Proof: How Defaults Burned Two Tenants We open with two Teams failure stories: Incident 1 – The Guest That Never Left A project ends. Champagne’s gone. One guest remains in the team.Private channel = separate SharePoint site; the guest’s sync client still points to that library.Weeks later, guest opens their laptop → the private channel library syncs fresh sensitive files down automatically.What failed: No guest expirationNo Entra ID access reviews for the teamExternal sharing too loose for private-channel SharePoint sitesOwners assumed “project over” = “access over.” It wasn’t.Blast radius: Sensitive docs in the private channel siteMeeting recordings, Loop components, and thread-linked filesAll delivered via SharePoint sync—no need to open Teams at allIncident 2 – PII Paste and the Data Fork A tired internal user pastes SSNs and bank details into a Teams channel.Someone copies it to email for a vendor. Another exports the thread.PII now lives in Teams, Exchange, local drives, and third-party systems. Cleanup becomes a scavenger hunt.What failed: No Purview DLP for Teams chat & channelsNo policy tips, no block-with-override, no compliance alertTeams treated like a front-end; core controls (Purview, Entra, SharePoint) were never tunedKey takeaway: Teams isn’t the vault. It’s the lobby. The vault lives in Conditional Access, Purview DLP, Entra ID Governance, and SharePoint sharing policies. From here, we build the five layers that would have shut both incidents down. Layer 1 – Conditional Access Baseline That Actually Bites Goal: Identity is the lock. Make it hurt to be misconfigured. You’ll hear a complete Conditional Access baseline: MFA for Everyone (Including Guests)Entra policy: All users (including Guests and external) → All cloud apps.Grant: Require MFA.Exclude only two break-glass accounts with long random passwords, monitored and stored offline.Kill Legacy AuthenticationNew policy targeting Exchange ActiveSync and Other clients.Grant: Block access.Starves phish and breaks old clients that can’t do MFA.Require Device Compliance for Crown AppsScope: internal users (and guests where feasible).Apps: Teams, SharePoint Online, Exchange Online.Grant: Require compliant device (Intune)For BYOD/mobile: cloned policy using “approved client app” + app protection instead.Session Controls & Risk-Based PoliciesShort sign-in frequency (e.g., 8 hours) and weekly reauth for sensitive apps.Enable Continuous Access Evaluation (CAE) so password changes and account disables kill live sessions.Extra policies for high-risk sign-ins/users → block or force password change and investigation.Guest & Service Account Edge CasesEnsure guests hit MFA at first sign-in.Disable interactive sign-in for service accounts; move to workload or managed identities.Regularly test break-glass accounts and CAE behavior.The point: MFA enforced, legacy auth dead, only trusted devices, short sessions, and real risk-based gates. Layer 2 – Purview DLP for Teams Chat & Channels Goal: Sensitive data should trip a wire the second it hits chat. Configuration you’ll walk through: Purview DLP Policy targeted specifically to:Teams chat and Teams channel messagesSensitive Info Types:SSNs, credit cards, bank accounts, health data, and custom IDs (employee/customer IDs, etc.).Rules:High-confidence block with overrideMatch = 1 for crown jewels (SSN, PAN with Luhn, etc.).Block message; allow override with typed justification.Real-time policy tip to user + high-severity alert to compliance.Medium-confidence educate & alertAllow message but warn user and notify compliance for tuning and behavior change.Extras: Mirror policies to SharePoint/OneDrive so files + links are both covered.Tune confidence and match counts to kill noise.Use policy tips that explain in plain language, not legalese.Pilot, tune, then roll out by department → finally org-wide. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support. Follow us on: LInkedIn Substack

    26min
  5. Your "Hybrid Security" Is A Lie: Why Defender XDR Is Mandatory

    HÁ 2 DIAS

    Your "Hybrid Security" Is A Lie: Why Defender XDR Is Mandatory

    You’ve got six dashboards and three vendors, but attackers still stroll through the gaps between email, identity, endpoints, and cloud apps. In this episode, we break down why siloed tools fail in hybrid environments and how Defender XDR fuses Microsoft 365, Entra ID, endpoints, and cloud apps into one incident story with one timeline. You’ll see how attackers live in your blind spots—and how XDR uses cross-domain correlation, auto-response, and unified incidents to flip Microsoft security from “expense” to “savings.” Opening – The Illusion of “Hybrid Security” Control You’ve got dashboards, vendors, and a color-coded incident spreadsheet. It looks like control—but it’s really a Rube Goldberg machine that alerts loudly and catches little. Hybrid security isn’t “more tools”; it’s two overlapping attack surfaces pretending to be one. This episode exposes the four blind spots your silos hide: Microsoft 365 (email & collaboration)Identities (on-prem AD + Entra / Azure AD)Endpoints (EDR, laptops, servers)Cloud apps (SaaS, OAuth, shadow IT)Then we show how Defender XDR pulls them into one incident, one timeline, one response—and the one capability that turns XDR from a cost center into an actual savings engine. Segment 1 – Why Siloed Security Fails in Hybrid Environments We start with the foundation: why your current hybrid stack keeps burning you. Hybrid reality: on-prem AD limping along, Entra ID doing the real work, roaming laptops, and SaaS your team “definitely ran by security.”Every separate tool creates context debt:Email sees a phish.Identity sees risky sign-ins.Endpoint sees weird PowerShell.Cloud app security sees rogue OAuth consent.Individually “low”, together a live intrusion.Key ideas: Your SOC becomes the RAM, manually correlating alerts that should already be fused.Alert fatigue is a tax, not a feeling—paid in dwell time, overtime, and missed signals.Tools say “something happened.” What you need is: “what happened, in what order, across which domains.”Defender XDR shift: Instead of four tools and four tickets, you get one incident graph that ties mailbox rules, consent grants, tokens, endpoint processes, and cloud sessions to the same user and device. The platform does the stitching; your team does the deciding. Blind Spot 1 – Microsoft 365 Without Identity Fusion Email is still where most intrusions start—but not where they end. Common failure pattern: Phish lands → you quarantine the email → “incident closed.”Meanwhile:User clicks “Accept” on a malicious app (“Calendar Assistant Pro”).Attacker moves from mailbox → OAuth + Graph.Mail is quiet, but tokens and consent now carry the breach.Why this is a blind spot: M365 has rich telemetry (delivery, Safe Links, mailbox rules, Teams shares) but in an email silo it’s just noise.Different teams clear their own console and declare victory; nobody sees the token, consent, and endpoint together.Defender XDR advantage: Builds one incident that links:Phish in OutlookEntra sign-ins and token issuanceEndpoint process chain (Office → PowerShell)Cloud app and SharePoint file accessAuto-IR can:Isolate the deviceRevoke user sessions and tokensKill malicious OAuth consentRoll back mailbox rules – from one pane, not four.Result: fewer reinfection loops where the email is clean but the token and OAuth grant live on. Blind Spot 2 – Identities Without Endpoint and App Context Identities are the keys. Attackers don’t just steal passwords—they steal sessions, tokens, and consent. Identity-only failure patterns: Azure AD / Entra flags risky sign-ins, impossible travel, anonymous IP.The fix is: password reset, MFA enforced, risk lowered → incident closed.But:Refresh tokens still validOAuth grants still activeCompromised device still leaking cookiesWhy identity in a silo lies: No view of endpoint posture (was the machine already dirty?).No view of cloud apps (did a new app just start scraping SharePoint?).No linkage to mailbox rules or consent events.Defender XDR advantage: Risky sign-ins are fused with:Device health & process lineageOAuth consent and Graph behaviorSharePoint downloads and Teams activityAuto-IR can:Revoke refresh tokensKill active sessionsMark the user risky and isolate the deviceSurface mailbox rules and OAuth grants tied to that identityIdentity is no longer just a risk score; it’s part of a cross-domain incident story. Blind Spot 3 – Endpoints Without SaaS and Identity Context Endpoints are where the noise is—but not always where the breach lives. Endpoint-only loop: EDR flags Office → PowerShell → suspicious script.You block, isolate, reimage.But the attacker keeps a browser token and OAuth grant, and continues exfiltration from a different device or cloud host.Problem: Processes don’t show how the attacker got there (phish, consent, token).EDR can’t see Graph API exfiltration or SharePoint sessions.You treat symptoms; the root cause (identity + consent) lives upstream.Defender XDR advantage: Endpoint alerts are tied to:The specific user and sign-insThe token issued in the browserThe app consent that followed the phishThe cloud sessions that moved data outCorrect order of response:Kill token + sessions → revoke consent → then isolate/reimage.You stop “clean endpoint, dirty identity” from bouncing back every week. Blind Spot 4 – Cloud Apps & Shadow IT Without Identity / Device Linkage Cloud apps are where your data lives—and where shadow IT quietly routes exports and reports out of the tenant. Typical CASB-only view: Sees “high-risk OAuth grant” or “unusual SharePoint downloads.”Lacks:Device context (was the browser compromised?).Identity history (was there a phish or risky sign-in?).Unified response (can’t revoke tokens, isolate device, fix mail).Defender XDR advantage: Defender for Cloud Apps signals live inside the same incident graph:OAuth consentSession details Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support. Follow us on: LInkedIn Substack

    26min
  6. The M365 Attack Chain Is Not What You Think

    HÁ 2 DIAS

    The M365 Attack Chain Is Not What You Think

    Perimeter defense is a lie. In this mission briefing, we walk through a real-world style Microsoft 365 breach where attackers use consent phishing, AiTM token theft, and OAuth abuse to bypass MFA, replay stolen cookies, and live off the land with Microsoft Graph. You’ll see the exact Entra logs, Sentinel analytics, and controls that matter—plus the one policy that breaks the entire attack chain: consent control. If you run M365, Entra ID, or Sentinel, this is mandatory listening. Opening – The Lie of Perimeter Defense Officers, you’re briefed into a different war. Firewalls guard borders, but modern attacks don’t cross borders—they hijack identity. MFA looks like a shield, but stolen tokens and consented apps glide past it like cloaked ships. In this episode, we map an end-to-end Microsoft 365 breach: Starting in the attacker’s cockpitFollowing consent phishing, AiTM token theft, and OAuth abuseEnding with concrete detections (KQL, Sentinel) and Entra policies you can deploy todayThere is one policy that breaks this chain. Stay sharp. Segment 1 – Threat Intel Brief: What Modern Crews Actually Do We begin with the current threat picture: Phishing-as-a-Service & AiTM kits: turnkey infrastructure to steal credentials and session cookies together.Malicious multi-tenant OAuth apps: used as roaming “gunships” across tenants, abusing legitimate Microsoft identity flows.Goal set:Take the mailboxSiphon SharePoint / OneDrivePersist via app consent, refresh tokens, and mail rulesWhy traditional defenses fail: MFA stops passwords—not replayable sessions.Admin portals don’t highlight OAuth sprawl or service principals by default.Telemetry exists, but detection rules and UEBA are often missing or under-tuned.Telemetry that actually matters: Entra ID / Azure AD“Consent to application”“ServicePrincipal created”“AppRoleAssignedTo”Sign-in logs with “Authentication requirements satisfied” (including cookie replay patterns)Exchange / MailboxAuditNew inbox rules, hidden rules, external forwardingSharePoint / Unified Audit LogFileAccessed / FileDownloaded with AppId stampsApp registrations & service principalsNew credentials, updated permissions, scope creepKey doctrine: Don’t just guard logins—bind tokens and govern consent.Use Token Protection and risk-based Conditional Access to make stolen cookies worthless and cut risky sessions mid-flight.Segment 2 – Initial Access: Consent Phishing + Token Theft Here’s how the breach starts: User hits an AiTM phishing page (invoice, payroll, SharePoint link).Reverse proxy relays real Microsoft login → MFA succeeds → session cookie is captured.In the same flow, a benign-looking multi-tenant OAuth app asks for consent:Scopes like User.Read, Mail.Read, offline_accessThe user approves.Attacker now holds:A stolen cookie (for replay)A sanctioned service principal (for long-term Graph access)Key telemetry & detections: Entra Audit:“Consent to application” → “ServicePrincipal created” → “AppRoleAssignedTo”Entra Sign-in logs:“Authentication requirements satisfied” from a new device / country minutes after the real loginExchange MailboxAudit:Inbox rules or forwarding after consent (to blind the user)Unified Audit / SharePoint:FileAccessed / FileDownloaded showing an AppId instead of Outlook/browserDetection ideas: Sentinel analytics for consent events by high-value users or unfamiliar IPsWatchlists of sanctioned AppIds; anything else is priorityUEBA for impossible travel and sudden session switching that screams hijackAlerts on new service principals with scopes like Mail.ReadWrite, Files.Read.All, Sites.Read.All, offline_accessQuick wins: Disable user consent tenant-wide or limit to low-risk scopes + verified publishers.Enable admin consent workflow for everything else.Turn on Token Protection for Exchange/SharePoint where supported.Use Conditional Access (sign-in risk, compliant device, workload-specific controls) to block risky replay.Segment 3 – Persistence: Living Off the Land with OAuth & Mail Rules Once inside, attackers shift from sprint to residency: offline_access + refresh tokens = long-lived Graph access without the user.Hidden inbox rules hide security emails and alerts.A second, more “normal” app may be deployed as a backup persistence mechanism.Scopes quietly upgrade over time from Mail.Read → Mail.ReadWrite, Sites.Read.All → Files.Read.All.Telemetry & detections: Entra Audit:Update application, Add passwordCredential, Add keyCredential on service principalsAppRoleAssignedTo:Scope creep to high-value permissionsExchange MailboxAudit / Admin logs:New inbox rules, external forwarding, mailbox configuration changesSentinel:Analytics for external forwarding rulesUEBA for Graph call volume spikes from a single AppIdRemediation doctrine: Revoke app consent and delete OAuth2PermissionGrants for malicious apps.Disable or delete service principals; rotate secrets for legitimate apps that may be impacted.Force sign-outs, revoke refresh tokens, and require re-auth for affected identities.Implement Conditional Access session controls and Token Protection so replay dies at the gate.Segment 4 – Lateral Movement: From Mailbox to SharePoint to Keys With persistence established, attackers move laterally: Use mailbox intel to find:Project code namesSharePoint site URLsVendors and payment flowsUse Graph with Sites.Read.All / Files.Read.All to enumerate and harvest high-value content.Use directory read scopes to map admins, groups, app roles, and further targets.Launch BEC-style attacks using real threads and context. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support. Follow us on: LInkedIn Substack

    27min
  7. Your MFA Is Useless: The Entra ID Attack Nobody Audits

    HÁ 3 DIAS

    Your MFA Is Useless: The Entra ID Attack Nobody Audits

    This episode is a drill for security leaders, identity admins, and anyone running Microsoft 365 / Entra (Azure AD). We walk through how attackers weaponize OAuth consent—not password theft—to gain persistent access to email, files, and directory data without triggering traditional MFA defenses. You’ll hear a full breakdown of: What illicit consent grants really areHow refresh tokens and offline_access keep attackers in even after you reset passwordsThe three Entra controls that collapse most of this attack surfaceHow to detect, prove, and remediate malicious OAuth grants in your tenantIf you think “we forced sign-out and reset passwords, so we’re safe,” this episode is your wake-up call. What You’ll Learn in This Episode What Illicit OAuth Consent Grants Actually Are Why this is authorization abuse, not credential theftHow a “harmless” Microsoft consent screen turns into:Mail.Read / Mail.ReadWrite → inbox and attachment visibilityFiles.Read.All / Files.ReadWrite.All → SharePoint & OneDrive sweepDirectory.ReadWrite.All → identity pivot and tenant tamperingWhy MFA doesn’t fire: the app acts with your delegated permissions, using tokens, not loginsThe critical role of offline_access as a persistence flag2. Why MFA and Password Resets Don’t Save You How refresh tokens keep minting new access tokens long after you:Reset passwordsEnforce MFA“Force sign-out” for a userWhy OAuth consent lives in a different lane:User authentication events vs. app permission eventsWhy revoking the grant beats resetting the password every timeDelegated vs. application permissions:Delegated: act as the userApplication: act as a service, often tenant-wide3. The Three Non-Negotiable Entra Controls You Must Set You’ll get a clear checklist of Entra ID / Azure AD controls: Lock Down User ConsentDisable user consent entirely orAllow only verified publishers and low-risk scopesExclude: offline_access, Files..All, Mail.ReadWrite, Directory.Require Verified PublishersOnly apps with Verified Publisher status can receive user consentForce attackers into admin consent lanes where visibility and scrutiny are higherEnable & Enforce Admin Consent WorkflowRoute risky scope requests (Mail.Read, Files.ReadWrite.All, Directory.ReadWrite.All, etc.) into a structured approval processRequire justification, business owner, and expiry for approvalsUse permission grant policies and least privilege as the default4. Case Study: Proving MFA & Resets Don’t Revoke Grants We walk through a clean, reproducible scenario: User approves a “Productivity Sync” app with Mail.Read + offline_accessAttacker uses Microsoft Graph to read mail and pull attachments—quietlyBlue team resets password, enforces MFA, forces sign-outApp keeps working because the OAuth grant and refresh token still existThe only real fix: revoke the OAuth grant / service principal permissionsYou’ll come away with a mental model of why your normal incident playbook fails against app-based attacks. 5. Detection: Logs, Queries, and What to Flag Immediately We cover the high-signal events and patterns you should be hunting: Key audit events:Add servicePrincipalOAuth2PermissionGrantUpdate applicationAdd passwordCredential / Add keyCredentialHow to triage suspicious apps:Unknown service principalsUnverified publishersHigh-risk scopes: offline_access, Mail., Files..All, Directory.*Inventory & queries (Graph / PowerShell) to map:Who granted whatWhich apps hold risky scopesTenant-wide consents (consentType = AllPrincipals)6. Remediation & Hardening: Purge, Review, Enforce, Repeat You’ll get a remediation playbook you can adapt: Immediate:Remove OAuth2PermissionGrants for malicious appsRemove or rotate app secrets and certificatesDelete rogue service principalsAssessment:Review mailbox, SharePoint, and directory impact based on granted scopesHardening:Implement deny-by-default permission grant policiesBuild a scope catalog of: allowed, conditional, and blocked scopesSchedule recurring access reviews for apps and consentsDashboard: long-lived grants, risky scopes, and grants to privileged usersWho This Episode Is For CISOs & security leaders running Microsoft 365 / Entra IDIdentity & access management teamsSOC & detection engineersCloud security / platform engineering teamsRed teams & blue teams modeling OAuth abuse and MFA bypassKey Terms Covered OAuth Consent / Illicit Consent GrantsRefresh Tokens & offline_accessDelegated vs. Application PermissionsAdmin Consent WorkflowVerified PublisherService Principal & OAuth2PermissionGrantMicrosoft Graph–based exfiltrationCall to Action Next steps after listening: Lock user consent: restrict or disable it, and remove offline_access from low-risk scopes.Enable Verified Publisher enforcement for all user-consent scenarios.Turn on and use Admin Consent Workflow—no more “one-click tenant skeleton keys.”Audit existing grants for offline_access + *.All scopes and revoke anything suspicious.Subscribe for the follow-up episode on real Microsoft Graph queries and KQL detections to automate this hunt. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support. Follow us on: LInkedIn Substack

    29min
  8. The Doctrine of Distribution: Why Your Power BI Reports Require Apostolic Succession

    HÁ 3 DIAS

    The Doctrine of Distribution: Why Your Power BI Reports Require Apostolic Succession

    Dear congregation, we scatter reports like leaves in a high wind. And then we wonder why no one can find the tree. Most think a quick share link is harmless. But it breaks lineage, weakens truth, and breeds confusion.Here’s what actually happens when we abandon governance. Manual chaos. Broken RLS. Stale workspaces that quietly mislead. We will establish a sacred pattern. Authoritative datasets. Faithful distribution through Org Apps. And staged deployments as our liturgy. You will leave with a clear pathway to migrate, to adopt pipelines, and to guard access with labels, roles, and tenant discipline. There is one covenant that makes this endure—stay with us.Section I: The Heresy of Manual Sharing—Why Lineage Fails Without Stewardship (650 words)Dear congregation, let us name the sin plainly. Ad‑hoc share links. Email PDFs. Orphaned bookmarks in private folders. No lineage. No accountability. Just fragments of truth torn from their source and traded like rumors in a marketplace.What follows is predictable. Conflicting truths. Two dashboards, same title, different numbers. One copy carries last month’s calculation. Another carries a developer’s untested change. Leaders ask which one is real. We answer with guesses. Wisdom weakens. Community frays.Audit blindness arrives next. When a link spreads beyond our sight, there is no canonical place to trace who saw what and when. We cannot answer basic questions with confidence. Who consumed the sensitive page? Who exported the detailed table? We grope in the dark where we should stand in the light.Then RLS drifts. Roles meant to protect the flock are re‑implemented in each copy. A filter is missed. A condition is inverted. One region sees another’s ledger. Or a manager loses access to their own staff. Exposure and withholding. Both harm the body.Discoverability dies as well. Users beg for links. New joiners ask in chat. Knowledge becomes a scavenger hunt. We shape a culture of favors instead of a pathway of order. When the path is unclear, shadow guides appear. “Use my version,” they say. And the canon fractures.Hold this moral frame. Data without stewardship becomes rumor. Rumor erodes trust and community. We do not gather to trade rumors. We gather to receive truth, to work in unity, to decide with clarity. That requires a doorway. Not a pile of keys.Org Apps are that canonical doorway. The sanctuary where truth is received, not scattered. One entrance. Ordered content. A visible covenant between producers and consumers. When we bless an Org App, we declare: this is where the faithful will find the latest, tested, endorsed truth. Not in a forwarded file. Not in a private bookmark. Here.But hear the warning. Even a doorway fails if the locks are broken. A beautiful entrance means little if the walls do not hold. So let us examine why manual sharing weakens the very locks we rely on.First, lineage. When reports are shared by link outside the app, the chain from report to dataset to certification is hidden from view. Users cannot see endorsements. They cannot see who owns the data. They cannot see refresh health. They consume without context. They decide without confidence.Second, navigation. Manual sharing bypasses the curated order of pages, sections, and overview. The user lands in the middle of a story. They miss the preface. They misunderstand the conclusion. An Org App offers liturgy. Sections for reports. Sections for notebooks. An overview that teaches how to walk. Links that bridge only to governed sources. Manual sharing tears out the bookmarks and throws away the map.Third, change management. A link to a draft becomes a lifeline for a team that never should have seen it. A PDF from a test workspace circulates for months. Meanwhile, the production app is updated and blessed. Manual sharing ignores versions. It creates a chorus of unsynchronized hymns.Fourth, stewardship. Org Apps show owners. They show endorsements. They show labels. They show when content was refreshed. Manual shares hide all of this. They turn stewards into rumor chasers. They replace pastoral care with firefighting.Fifth, culture. When the default is “send me the link,” we teach impatience. We teach exception. We teach that governance is optional when a deadline looms. But remember this truth: haste without order leads to error without mercy. We must teach the community to enter through the door, not climb through the window.So how do we turn? We commit to a simple practice. We publish to a workspace with intention. We build the Org App as the sole doorway. We remove alternate paths. We instruct: if it is not in the app, it is not ready. If it lacks an endorsement, it is not trusted. If it lacks a label, it is not classified. If it bypasses navigation, it is not part of the story.And yet, even with a doorway, we must keep the walls. RLS and OLS are sacred boundaries. They do not live in emails. They do not survive exports. They live in the dataset and in the app’s audiences. Align them. Test them. Guard them. Because once boundaries drift, the sanctuary loses its shape.We have named the heresy of manual sharing. We have seen its fruits: conflicting truths, audit blindness, role drift, and lost pathways. Let us not return to scattered leaves. The doorway stands ready. But to keep it strong, we must speak of guardianship. We must speak of RLS.Section II: When RLS Breaks—Guardianship, Not GuessworkDear congregation, let us face the wound. When RLS breaks, it exposes or withholds. Both harm the body. Exposure shames trust. Withholding starves decision. The sanctuary trembles, not because the data is wrong, but because the boundary failed.Why does it fail? Copies of datasets, each with its own roles. Mismatched role names between environments. Unmanaged audiences that reveal pages to the wrong flock. Brittle testing, done by authors alone, never by the people who actually live inside the rules. These are not accidents. These are practices. And practices can be changed.Hold the law: RLS and OLS are sacred boundaries. They are not suggestions. They are walls. They are doors with names carved above them. They tell each person, “Enter here. Not there.” So we honor them at the source. We model roles at the dataset. We do not patch filters in a report. We do not rely on page‑level illusions. We bind row filters and object limits where the truth is born.Practice this discipline. Start with clear personas. Finance analyst. Store manager. Regional VP. Vendor. Build a test matrix. For each persona, define expected rows, restricted columns, allowed pages, and forbidden exports. Then test in the service, not only in Desktop. Use “view as” with sample users tied to Azure AD groups. Prove that a user in one congregation sees only their pasture. Prove that a steward can survey the field without crossing into private fences.Now, this is important because roles are more than DAX filters. They are relationships. The role name must persist from Development to Test to Production. If the mapping breaks in one stage, drift begins. So we standardize role names. We store them in source control with the PBIR and dataset settings. We script assignments where we can. We document the covenant in plain language. When roles read like scripture, people keep them.App audiences stand beside those roles like ushers at the door. Align them deliberately. Leadership, managers, frontline. Each audience receives only the sections that serve their duty. Do not let navigation cross‑contaminate. Do not show a tab that a role cannot open. Hidden is not governed. Remove what is not theirs. Show what is. This reduces curiosity that tempts boundary testing. It also teaches the user: your path is clear, your duty is enough.Bind sensitivity labels to content as visible vows. If the dataset is Confidential, the report inherits the mark, and the app displays it. Teach the label to travel. Into exports. Into Teams. Into SharePoint. Into email. A label is not decoration. It is a promise that follows the artifact wherever it goes. Without that promise, a harmless screenshot becomes a breach.Define tenant settings as the covenant’s outer wall. Who may publish beyond the organization? Who may share externally? Who may build on certified datasets? Do not leave this to whim. Enforce through security groups. Review quarterly. Record exceptions. We are not closing the gates to keep people out. We are closing the gates to open the right doors with confidence.And yet, even faithful walls require proof. So we test with time. We test after every schema change. We test after role membership shifts in HR. We test when a new region is born. Automate checks where possible. Validate that each audience lands on an allowed page. Validate that each persona returns only their rows. Put a health tile on the steward’s dashboard that turns red when a role assignment is empty, a filter returns zero rows unexpectedly, or a label is missing.Remember this: never patch at the edge. Do not fix a broken role by hiding a visual. Do not fix a leaked column by formatting it blank. These are fig leaves. They cover, but they do not heal. Return to the dataset. Repair the role. Re‑publish through the pipeline. Announce the change in the app’s notes. The body deserves healing, not concealment.Guardianship is not guesswork. It is design. It is rehearsal. It is watchfulness at dawn and dusk. When we keep these boundaries, the sanctuary holds. And the work can proceed in peace.Section III: Stale Workspaces—When the Lamp Goes OutDear congregation, let us walk the nave at night. The lamp has gone out. In forgotten corners, old visuals still glow. A retired dataset hums softly. A bookmark points to a page that no longer speaks. No one tends it. And yet people still come, and they still believe.This is the drift. Abandoned workspaces. Outdated measures that once served well but now mislead. Reports named “Final_v7” that never reach

    30min

Sobre

Welcome to the M365 Show — your essential podcast for everything Microsoft 365, Azure, and beyond. Join us as we explore the latest developments across Power BI, Power Platform, Microsoft Teams, Viva, Fabric, Purview, Security, and the entire Microsoft ecosystem. Each episode delivers expert insights, real-world use cases, best practices, and interviews with industry leaders to help you stay ahead in the fast-moving world of cloud, collaboration, and data innovation. Whether you're an IT professional, business leader, developer, or data enthusiast, the M365 Show brings the knowledge, trends, and strategies you need to thrive in the modern digital workplace. Tune in, level up, and make the most of everything Microsoft has to offer. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support.

Você também pode gostar de