标签：#Azure

Device Code Flow abuse is not a new technique. Security teams have known for some time that this OAuth feature can be leveraged in phishing attacks to obtain tokens without stealing credentials. What is new is how accessible and scalable this attack has become. In April 2026, the FBI warned about a Phishing-as-a-Service (PhaaS) platform called Kali365, which operationalizes this exact technique. It allows even low-skilled attackers to run campaigns that trick users into entering device codes on legitimate Microsoft login pages — ultimately granting attackers OAuth tokens and acess to Microsoft 365 environments without triggering traditional authentication defenses. How Device Code Flow Works Device code flow is an authentication method designed for scenarios where a device has limited input options or lacks a convenient browser interface (such as smart TVs, IoT devices, or command-line tools). Instead of entering credentials directly on the device, the application generates a verification code and displays it. The user then switches to a secondary device (such as a laptop or smartphone), navigates to https://microsoft.com/devicelogin , and enters the provided code. After successfully authenticating, the identity provider securely links the session and grants the original device access to the requested resource. Why Device Code Flow Should Be Restricted In practice, many organizations don’t have a real or current business need for device code flow, yet leave it enabled—unnecessarily expanding their attack surface. Disabling it helps reduce exposure by removing a legacy or rarely used authentication path and reinforces modern controls. Microsoft recommends getting as close as possible to a full block. Start by auditing existing usage, validate whether any legitimate scenarios still require it, and strictly limit access only to well-defined, secured, and documented use cases (e.g., specific legacy tools). In all other cases, device code flow should be disabled by defau

Originally published at https://rnye.tech Hi all, today's post details an interesting problem that faced a website thanks to undocumented Google crawl behaviour that hit us suddenly. The website used Azure Front Door for global CDN/WAF capability but only had one origin - hosted in Azure in the UK South region. This should have been fine given it's a UK-centric site that receives very little global traffic - that is until Google starts crawling you from the West Coast of the US suddenly. Let's dive in. The problem: what Google Search Console was telling us All was well with the site from the UK, cache hit ratios were in the 80%+ range, response times were generally rapid even if cache was missed. Google typically crawled the site thousands of times a day. Then suddenly a ticket came in detailing a drastic drop-off in mid-April. Average response times were never great according to Google (700ms) but they'd suddenly jumped to almost double that number (1.3s) with seemingly no explanation. There was absolutely no denying the correlation between crawl requests and average response time, and indeed this is documented behaviour - if response times increase, Google backs off. They claim it's to prevent overloading the site, and I believe that, but I also feel it's likely to ensure they're not wasting their crawl compute resources on long-loading pages. Either way, Google Search Console offered zero explanation as to why. So the team did what most dev/devops teams do - review latest changes, any Azure Front Door configuration changes in particular, as well as wider site changes. And nothing correlated. AFD hadn't been changed for two weeks, it was that stable, and other changes weren't remotely related. Besides, genuine traffic in the UK wasn't seeing the impact. Response times were still good in the P50/P90/P99 metrics. Tracing the cause with Azure Front Door logs and AI As I've touched on in my last post , AI can be fantastic at quick data analysis. That's not to say a hu

I've been running AI workloads on Azure Container Apps for over a year. Every time I spin up a new agent backend, the ritual is the same: create an environment, configure networking, set scaling rules, wire up health probes, then deploy the actual container. For a prototype agent that might live for a week, that's too much ceremony for what you get. ACA Express, which hit public preview in May 2026, kills most of that ceremony. And a separate but related announcement, Docker Compose for Agents, brings MCP gateways and model serving to standard ACA environments. They solve different problems and run on different infrastructure, but together they cover the full spectrum of agent deployment on Azure. Let me break down both. ACA Express: What It Actually Is Express is a new environment tier within Azure Container Apps. You bring a container image. Express handles provisioning, HTTPS, scaling (including scale-from-zero with subsecond cold starts), and resource allocation. No environment to manually provision through the portal. No networking to configure. No scaling rules to write. Under the hood, Express is built on ACA Sandboxes, a platform primitive that uses prewarmed pools to deliver that subsecond startup. This isn't the standard ACA cold-start experience with a fresh coat of paint. It's a different architecture. The tradeoffs are real. Express is HTTP workloads only, consumption CPU only. No GPU. No VNet integration. No Dapr. No service discovery between apps. No managed identity at runtime. No health probes. If you need any of those, standard ACA environments are still there. But for stateless HTTP agent backends, Express is dramatically faster to deploy and cheaper to run. Here's what it takes to get a container running: # Create an express environment az containerapp env create \ --name my-express-env \ --resource-group rg-my-agents \ --environment-mode express \ --logs-destination none # Deploy your app az containerapp create \ --name my-agent-api \ --resource

Microsoft added sandboxed code interpreters to Azure Logic Apps, enabling agents within integration workflows to generate and execute Python, JavaScript, C#, and PowerShell in Hyper-V isolated sessions. Architects get full control over model selection per workflow. The capability positions Logic Apps as an agent platform for integration alongside Foundry and Copilot Studio. By Steef-Jan Wiggers