A Cloud Guy – Page 5 – Azure, M365, AWS and IT in general

The Hidden Threat in Plain Sight: Understanding and Securing Exchange Online’s Direct Send

July 21, 2025June 22, 2025 by Kumaran

In the ever-evolving world of cloud security, sometimes it’s not the new, complex exploits that catch us off guard, it’s the overlooked features hiding in plain sight. One such feature in Exchange Online is Direct Send, a capability designed for convenience but now actively exploited by attackers to bypass security controls.

Let’s pull back the curtain and take a deep dive into what Direct Send is, how it’s being misused, and what you can do to shut the door on this attack vector.

Table of Contents

What Is Direct Send in Exchange Online?

Direct Send is a feature that allows internal devices or applications (like printers, scanners, or legacy tools) to send emails through Microsoft 365 without authentication.

It works by leveraging the tenant’s smart host, typically in the format:

tenantname.mail.protection.outlook.com

Originally designed to help internal tools send alerts or reports to internal mailboxes, Direct Send does not require credentials or tokens. That’s the convenience. But therein lies the danger.

Key Detail: Direct Send only works for recipients within the same tenant, it won’t deliver mail to external domains.

How Direct Send Becomes a Security Risk

While Direct Send serves a legitimate purpose, it becomes a security liability because anyone with the right tenant domain and smart host format can spoof an internal sender. No login. No breach. Just open SMTP.

All an attacker needs is:

A valid tenant domain (easy to scrape from public records or previous breaches)
The smart host address (easily guessable)
An internal email format (like first.last@company.com)

With that, they can send spoofed emails that appear to come from inside the organization, bypassing both Microsoft’s and third-party email filters that trust internal traffic.

Real-World Abuse: How Attackers Exploit Direct Send

During a recent threat campaign observed across several U.S.-based organizations, attackers used PowerShell to exploit Direct Send, sending emails that looked like internal alerts, complete with subject lines like “New Missed Fax-msg” or “Voicemail received.”

Here’s a sample PowerShell command used:

Send-MailMessage -SmtpServer company-com.mail.protection.outlook.com `
  -To joe@company.com -From joe@company.com `
  -Subject "New Missed Fax-msg" `
  -Body "You have received a call! Click the link to listen." -BodyAsHtml

Since the emails originated from Microsoft’s infrastructure, many filters saw them as internal-to-internal traffic. This allowed them to sneak past SPF, DKIM, and DMARC checks, especially in tenants with lax anti-spoofing policies.

How to Detect Direct Send Abuse

You’ll need to dig into message headers and behavioral signals to spot these threats:

Message Header Indicators

Received headers showing external IPs sending to your smart host.
Authentication-Results failing SPF, DKIM, or DMARC checks.
X-MS-Exchange-CrossTenant-Id not matching your tenant.
SPF record mismatch or missing smart host entry.

Behavioral Indicators

A user “emailing themselves.”
Emails sent via PowerShell or unknown user agents.
Unusual IP addresses or geolocations.
Suspicious links, QR codes, or file attachments.

Remember, not all Direct Send traffic is malicious, context matters.

How to Disable or Control Direct Send

Microsoft now allows you to disable Direct Send entirely using a single command in PowerShell:

Connect-ExchangeOnline
Set-OrganizationConfig -RejectDirectSend $true

To verify:

Get-OrganizationConfig | Select-Object Identity, RejectDirectSend

Pro Tip: Disabling this feature won’t affect authenticated SMTP relay or Microsoft 365 apps, it only blocks unauthenticated Direct Send.

More details here: Microsoft’s announcement on Direct Send controls

Best Practices to Secure Your Tenant

Here’s a checklist to keep Direct Send from becoming your weakest link:

Disable Direct Send with RejectDirectSend = $true
Enforce DMARC with a strict policy (p=reject)
Flag unauthenticated internal emails for review or quarantine
Enable Anti-Spoofing Policies in Exchange Online Protection (EOP)
Enforce known IPs in SPF records to reduce spoofing
Educate users on phishing threats, especially QR code–based quishing
MFA + Conditional Access for all users

Final Thoughts

Direct Send was designed with good intentions but in the wrong hands, it becomes a fast-track lane for phishing campaigns. The good news? You now have the awareness and the tools to defend against it.

Don’t let this quiet feature become a noisy headline for your security team. Audit your tenant, close the loopholes, and stay vigilant.

Thanks for stopping by. ✌️

RBAC vs. ABAC in Azure: Why You Need Both for Cloud Access Control That Actually Works

July 21, 2025June 21, 2025 by Kumaran

Let’s cut to the chase, cloud access control isn’t just a checkmark on your compliance list anymore. It’s a daily battlefield. With global teams, hybrid workloads, and rising security risks, who can do what and under what conditions is now a core pillar of IT strategy.

If you’re working in Azure, you’ve likely heard of RBAC (Role-Based Access Control) and ABAC (Attribute-Based Access Control). But what you may not know is that these aren’t mutually exclusive instead they’re better together.

Let’s unpack what each model does, where they shine (and struggle), and how to combine them for airtight, scalable access governance in Azure.

Table of Contents

What is Azure Role-Based Access Control (RBAC)?

Azure RBAC helps you control access by assigning roles to security principals (users, groups, service principals, or managed identities) at a specific scope (subscription, resource group, or resource).

Each role is a bundle of permissions, think of them as job descriptions for Azure resources.

Example RBAC Use Cases

A user who can manage only virtual machines in the Dev subscription.
A group assigned the Reader role at the resource group level.
An app given Contributor access to only one storage account.

RBAC works well when your access needs are role-based and relatively straightforward. But as organizations scale and become more dynamic, things can get messy fast.

Where RBAC Falls Short

RBAC starts to creak when:

You need to create roles for every unique mix of region, team, and resource.
You end up with a Frankenstein monster of roles like:
- VP - Europe
- Manager - Asia
- SalesRep - NorthAmerica - Junior
You have hierarchical or multi-tenant data structures that don’t fit RBAC’s flat model.

The result? Role sprawl, administrative pain, and security gaps.

What is Azure Attribute-Based Access Control (ABAC)?

ABAC adds contextual smarts to access control. Instead of relying solely on roles, it factors in attributes of:

The user (e.g., department = HR)
The resource (e.g., tag = Project:Alpine)
The environment (e.g., access during business hours only)

In Azure, ABAC is implemented through role assignment conditions that filter RBAC permissions.

ABAC in Action

“Chandra can read blobs only if they’re tagged with Project=Cascade.”
“Support engineers can impersonate users only during a help session.”
“Users can access data only in their assigned region or cost center.”

This kind of fine-grained access is powerful, flexible, and crucial in multi-tenant, regulated, or fast-moving environments.

RBAC + ABAC: Not a Choice – A Collaboration

Here’s the mindset shift: RBAC and ABAC are not competing models. They’re complementary.

RBAC defines what actions are allowed.
ABAC defines under what conditions those actions are allowed.

By combining the two, you can:

Keep your role structure simple and understandable.
Layer on access conditions that reflect real-world business rules.

Common Hybrid Patterns

Scenario	RBAC Role	ABAC Condition
Multi-tenant app	Tenant Admin	Only for `tenant_id=X`
Regional access	Sales Manager	Region = “North America”
Subscription tiers	Premium User	Access feature only if `plan=premium`
File access	Editor	Only `owner=user_id` or `shared_with=user_id`
Support scenarios	Support Agent	Impersonation allowed if `user_in_session=true`

Best Practices for RBAC and ABAC in Azure

Let’s bring it home with the golden rules:

RBAC Best Practices

Least Privilege Always: Grant only the permissions needed—nothing more.
Limit Subscription Owners: Three max. The fewer, the safer.
Use PIM for Just-in-Time Access: With Microsoft Entra PIM, elevate access temporarily.
Assign Roles to Groups: Not individuals. Makes scaling and auditing easier.
Avoid Wildcards in Custom Roles: Be explicit with Actions and DataActions.
Script with Role IDs, Not Names: Avoid breakage from renamed roles.

ABAC Best Practices

Tag Strategically: Use meaningful tags like Project, Environment, or Classification to enable ABAC.
Use Conditions to Reduce Role Sprawl: Filter access with precision.
Start Small: Pilot with blob storage conditions before scaling ABAC elsewhere.
Don’t Replace RBAC: Use ABAC as a filter, not a replacement.

Recap: When to Use What

Feature	RBAC	ABAC	RBAC + ABAC
Simplicity	✅	❌	✅
Contextual Flexibility	❌	✅	✅
Scalability	⚠️ (sprawl risk)	✅	✅
Multi-Tenant Scenarios	⚠️	✅	✅
Least Privilege Enforcement	✅	✅	✅✅

Final Thoughts

RBAC gives you structure. ABAC gives you nuance. In Azure, using both gives you power and precision.

Don’t fall into the “either/or” trap. The real magic happens when you combine the predictability of RBAC with the intelligence of ABAC to build access models that scale with your business.

Thanks for stopping by. ✌

Managing Microsoft 365 and Azure with Lokka — Natural Language for Admins

November 9, 2025June 14, 2025 by Kumaran

Ever wished you could manage your Microsoft 365 tenant without juggling endless PowerShell scripts? Enter Lokka, your AI-powered sidekick that connects directly to Microsoft Graph and Azure APIs, so you can simply ask what you want.

Table of Contents

What Is Lokka (and What’s MCP)?

Lokka is a Model Context Protocol (MCP) server that acts as a translator between AI models (like ChatGPT or GitHub Copilot Agent) and your Microsoft 365 or Azure tenant.

The Lokka documentation includes a helpful diagram illustrating the overall flow.

Think of MCP as a USB-C port for AI tools, a universal interface that lets you securely connect an AI model to your Microsoft environment. Lokka bridges the gap so you can say things like:

“List all users without licenses.”
“Add Alex to the Network Admins group.”
“Show OneDrive accounts over 90% full.”

Instead of writing and debugging a PowerShell script, Lokka interprets your plain-English query and executes it via the Microsoft Graph and Azure Resource Manager APIs.

Setting Up Lokka

Lokka works as an MCP server that you connect through VS Code with the GitHub Copilot Agent. Here’s how to get it running.

Pre-requisites

Visual Studio Code (latest version)
GitHub Copilot Chat extension
Node.js installed (npx must be available)
Global admin or app registration permissions in Microsoft Entra

Step 1: Create a Microsoft Entra App

Before Lokka can talk to your tenant, it needs a Microsoft Entra (Azure AD) app for authentication.

Go to Microsoft Entra admin center → App registrations → New registration
Name it something like Lokka-Agent
Once created, note the Application (client) ID and Directory (tenant) ID

Add API Permissions

I enabled the following permissions. yes, it’s quite a list, but this is a test tenant after all. I wanted to push Lokka’s limits and see what it’s truly capable of. I recommend doing the same: experiment safely in a test environment first.

Once added, click Grant admin consent to approve them for the tenant.

Create a Client Secret

While certificate-based authentication is the best practice for Entra app registrations, I’m keeping it simple and using a client secret for this test setup.

Under Certificates & secrets, create a new client secret, copy the value now; you won’t see it again.

You’ll use these three values in Lokka’s config file:

{
  "clientId": "YOUR_CLIENT_ID",
  "clientSecret": "YOUR_CLIENT_SECRET",
  "tenantId": "YOUR_TENANT_ID"
}

Step 2: Install Lokka in VS Code

You can install Lokka two ways: one-click or manual.

Option 1: One-Click Install

Start VS Code and then click the button below to install Lokka in VS Code.
If your browser prompts you to open VS Code, click Open.
In the VS Code Lokka-Microsoft install page
- Click Install.
- Click the widget icon next to the button and select Start Server.
This will open a browser window and prompt you to sign into your Microsoft tenant.

Platform	VS Code	VS Code Insiders
Windows
macOS/Linux

Option 2: Manual Install

After the one-click install method gave me some trouble, I went ahead and followed the manual setup steps instead.

Open Command Palette → Ctrl + Shift + P
Search for MCP: Add Server…
Select Command (stdio)
Enter the following command: npx -y @merill/lokka
Name it Lokka-Microsoft and choose Global install
Save the generated JSON file with tenant id, Client id and client secret.

Step 3: Start and Configure the MCP Server

You can manually start Lokka anytime:

Open Command Palette → MCP: List Servers
Select Lokka-Microsoft → Start Server
A browser window will appear again to confirm sign-in

Once started, Lokka is ready to interpret your natural language requests.

Step 4: Using Lokka in Action

Start a new instance of VS Code (File > New Window)
Open Chat from View → Chat
At the bottom of the Chat panel (below the chat box)
- Select Agent (if it is showing Ask or Edit)
- Select Claude Sonnet 4 or above (if it is showing GPT-40)
Now you can start querying your Microsoft tenant using the Lokka agent tool.

Now for the fun part, try these commands inside VS Code’s Copilot chat:

Get all groups without owners
List users who haven’t signed in for 30 days
Show all unlicensed Microsoft 365 users
Add "Alex Johnson" to "Finance Team" group
Change job title of "Taylor Smith" to "Senior Engineer"
List users with mailbox forwarding enabled
List OneDrive accounts over 90% full
How many unused M365 licenses do we have?

Some of the prompts I tried,

No PowerShell scripting, no loops, no parsing JSON, just straightforward queries. Lokka translates them into Graph API calls behind the scenes.

Security Considerations

While Lokka is powerful, it’s only as safe as the permissions you grant. A few tips:

Start with read-only access — test and observe results first
Use a dedicated service account instead of your personal admin login
Rotate client secrets regularly and store them securely (e.g., Azure Key Vault)
Audit logs — monitor Graph API usage through Entra sign-in logs
Limit write permissions to specific tasks if you plan to use Lokka for automation

Why Lokka Beats Traditional Scripting

Let’s be honest: PowerShell is awesome but writing, debugging, and maintaining scripts takes time. Lokka lets admins ask, not script.

Faster insights without memorizing cmdlets
Easier collaboration, anyone can understand the query
Reduced context-switching between portals and terminals
Works naturally with GitHub Copilot and other MCP-enabled AI tools

In short: Lokka supercharges your admin toolkit, bridging natural language, AI, and your Microsoft tenant.

The Bottom Line

Lokka isn’t replacing PowerShell; it’s extending it into the AI era. Whether you’re managing licenses, auditing groups, or checking mailbox configurations, Lokka gives you conversational control of your environment, safely, efficiently, and intelligently.

Thank you for stopping by. ✌️

Azure’s Default Outbound Access Is Being Retired: What Cloud Admins Need to Know (and Do)

June 25, 2025June 7, 2025 by Kumaran

If you’re an Azure architect or admin and thought “default outbound access” was your silent wingman for VM connectivity, surprise! Microsoft is retiring it. After September 30, 2025, all new virtual networks in Azure will no longer support default outbound Internet access. Translation? If you’re spinning up VMs and expecting magic public IP access without configuring anything, those days are numbered.

Let’s break down what’s happening, why it matters, and how to prepare without losing your mind.

Table of Contents

What’s Being Retired?

Historically, Azure has provided what’s called default outbound access to virtual machines that don’t have an explicitly defined method of reaching the internet. Think of it as Azure tossing a temporary, shared public IP behind the scenes so your VM can connect out.

But that’s going away for all new VNETs after September 30, 2025.

Existing VNETs using default outbound access? You’re safe… for now.
New VNETs? You’ll need to be explicit.

No more “it just works” surprises. And honestly? That’s a good thing.

Why Is Microsoft Doing This?

Because “default” often equals “risky.” Here’s why the implicit setup has been problematic:

Unowned IPs: The IP addresses used for default outbound access are owned by Microsoft, not you. If they change, your workloads can break. And good luck explaining that to your CISO.
Lack of Visibility: These IPs aren’t traceable to your tenant, complicating logging and egress controls.
Zero Trust FTW: The shift aligns with modern security practices, explicit is better than implicit. You want to control your perimeter, not let Azure make assumptions for you.

This is a “secure by design” decision. We’re moving away from “let’s hope it works” to “I know exactly what’s happening and why.”

What You Need to Do Now

If you’re still relying on default outbound access in existing deployments: start transitioning. For all new virtual networks, you’ll need to plan outbound access explicitly. Microsoft recommends one of the following methods:

Explicit Method	When to Use It
Azure NAT Gateway	Best practice for scalable, consistent outbound IP
Standard Load Balancer (SLB)	Use when you already load-balance traffic
Public IP on NIC	Use when only one VM needs public connectivity

Bonus: Disable Default Access Explicitly

Even before the cutoff, you can preemptively disable default outbound access by enabling “Private Subnet” on your VNET or via PowerShell/CLI/ARM templates. Here’s the PowerShell approach:

$resourceGroupName = "<your-rg>"
$vnetName = "<your-vnet>"

$vnet = Get-AzVirtualNetwork -ResourceGroupName $resourceGroupName -Name $vnetName

foreach ($subnet in $vnet.Subnets) {
    $subnet.DefaultOutboundAccess = $false
}

Set-AzVirtualNetwork -VirtualNetwork $vnet

Why do this? Because some services like Windows Update and Windows Activation require explicit outbound connectivity anyway. Plus, it’s future-proof.

Gotchas to Watch Out For

Fragmented packets & ICMP: Not supported with default outbound IPs.
Multiple NICs or VMSS: IPs can change unpredictably when scaling.
NIC-level detection: Azure Advisor will still report default outbound usage unless the VM is rebooted after changing egress method.

Also note: Flexible orchestration mode for VMSS never uses default outbound. It’s already secure-by-default.

What’s Next?

Microsoft is nudging (okay, shoving) us toward better security hygiene. This is your nudge to revisit those old Terraform templates, ARM deployments, and quick-and-dirty test setups that assumed default behavior.

Checklist before September 30, 2025:

Inventory VMs using default outbound access
Decide on your preferred outbound method (NAT Gateway is a strong default)
Update IaC templates
Communicate with app teams about the change
Test egress-dependent services (patching, activation, APIs)

Final Thoughts

This isn’t just another checkbox compliance update, this is about control, visibility, and security. By requiring explicit egress, Microsoft is giving you more authority over your architecture.

It’s also a good reminder: just because something works “by default” doesn’t mean it should.

Thank you for stopping by. ✌️

Microsoft 365 Admins: June 2025 Brings Major Updates, Retirements & Action Items — Here’s Your Definitive Guide

June 2, 2025 by Kumaran

Buckle up, admins! June’s heating up with a fresh wave of Microsoft 365 changes. Whether you manage identity, information protection, collaboration, or compliance, there’s something here that will nudge your daily workflow—or bulldoze it if you’re not paying attention.

Let’s cut through the clutter. Below is your clear, actionable roundup of what’s coming, what’s going, and what needs your immediate attention across the Microsoft 365 landscape.

Table of Contents

In the Spotlight

Smoother OneDrive File Transfers

Say goodbye to clunky cleanup processes when employees leave. Microsoft’s new “Move and keep sharing” feature lets you transfer ownership while preserving existing sharing permissions. Combine that with new filters to zero in on important files and clearer notification emails, and you’ve got an admin’s dream come true.

Shared Mailboxes in New Outlook (Finally!)

The New Outlook for Windows now lets you add shared mailboxes like real accounts—no more backflips to get the same experience your users are used to. Easier management, better UX, happier end users.

Non-Profit Grant Offers Retiring

Heads up for non-profit orgs: Microsoft is retiring Microsoft 365 Business Premium and Office 365 E1 grant offers. If your licensing strategy includes these grants, now’s the time to rethink and re-budget.

June at a Glance

Category	Count
Retirements	4
New Features	10
Enhancements	9
Changes in Functionality	5
Action Needed	2

Retirements: What’s Going Away

Meeting Details in OneNote for Windows 10 – Poof, gone starting June 2025.
Private Content Mode in Viva Engage – Say farewell by June 30, 2025.
Teams Recording Initiator Policy – Both the MeetingInitiator value and MeetingRecordingOwnership setting will be retired by June 30, 2025.
Sports Calendars in Outlook – “Interesting Calendars” will vanish starting early June 2025.

New Features: What You’ll Want to Try First

Copilot Troubleshooter in Power Automate – Diagnose and resolve flow errors with a few clicks inside the designer.
Copilot for Security in Purview Insider Risk Management – Contextual alerts and smarter investigations—yes, please.
Data-at-Rest Scanning in SharePoint/OneDrive – Finally scan previously untouched files for sensitive info and apply sensitivity labels.
Microsoft Backup Enhancements – Define backup policies that automatically cover all Exchange, OneDrive, and SharePoint users—even new ones.
Automated Retention Actions in Gov Cloud – US government tenants can now use Power Automate to act on expired items.
50+ Modern SharePoint Page Templates – No more pixel-pushing—get sleek, branded designs in a click.
New Insider Risk Email Indicators – Spot emails with attachments sent to free public domains or to oneself—cue the red flags.
Risky AI Activity Detection – Admins can now monitor for sensitive prompt usage and sketchy AI behavior.
Microsoft Defender XDR Integration – Insider Risk data will now flow into XDR for unified investigations.
Fabric Network Enhancements (Preview) – Private links and outbound access controls to lock down Fabric workspaces like Fort Knox.

Enhancements: Refinements You’ll Appreciate

HR Connector in Insider Risk Management – Apply the updated PowerShell script or risk issues.
Exclude Folders from OneDrive Sync – Control bloat and protect endpoints.
Reduce Noise in Communication Compliance – Filter out newsletters and spam to surface real threats.
On-Demand Classification – Retroactively classify sensitive content in SharePoint/OneDrive.
New Teams Role: Teams Reader – View-only access in the admin center. Great for auditors or curious execs.
View and Upload Anyone Links – Strike a balance between accessibility and control.
Global Exclusions in Insider Risk – Now supports more logical rules to cut alert fatigue.
DLP + Administrative Units – SharePoint DLP policies can now be scoped by administrative units. Finally.
Targeted IRM Policies – Use combinations of users, groups, and adaptive scopes for laser-focused risk management.

Functional Changes: What’s Evolving

SharePoint Online CDN Migration – Allow public-cdn.sharepointonline.com and stop relying on hardcoded links.
Teams DLP Reports – Incident notifications now come from both old and new sender addresses.
Exchange Federation Cmdlet Changes – Get-FederationInformation is being scoped down.
Audit Log Cmdlets Go Read-Only – No changes/downloads after June for Search-MailboxAuditLog and New-MailboxAuditLogSearch.
Separate Policy Tip Settings – Customize email notifications separately for SharePoint and OneDrive DLP.

Action Needed: Do This Now

Viva Engage External Networks – Legacy networks will be retired June 1, 2025. Transition to modern external networks now to avoid disruption.
Microsoft Defender SIEM Agents – After June 19, 2025, no new agents can be configured. Move to supported APIs to future-proof your integration.

Final Thoughts

If you’re managing Microsoft 365 in an enterprise setting, June is a no-joke month for updates. With new features that improve automation, security, and governance—and retirements that could leave gaps if ignored—it’s vital to stay proactive.

Bookmark this post, forward it to your team, and prep your change calendar. Because in IT, those who fail to plan… usually end up on a 2 a.m. call with their CISO.

Stay sharp, stay current—and keep your tenant tight.

Thank you for stopping by. ✌️