Self-hosting applications on Windows servers can be deceptively complex when persistence, security, and reliability are required. This becomes especially true when deploying Linux-first platforms such as Immich in a domain-managed environment.

In this article, I document how I deployed Immich on a Windows Server using Docker Desktop and WSL, with media stored on a network file server and the database configured for long-term persistence.

The goal was simple: ensure the service survives reboots, upgrades, and redeployment without losing data.

What Is Immich?

Immich is an open source, self hosted photo and video management platform designed as a privacy focused alternative to services such as Google Photos.

It consists of multiple containerised services, including a web interface, machine learning components, PostgreSQL for metadata storage, and a Redis compatible cache. It is designed primarily for Linux based container environments.

Project Objectives.

Before starting, the deployment had several clear goals:

• Host Immich on a Windows Server platform.

• Use Docker containers for portability.

• Store uploaded media on a central file server.

• Prevent database resets after reboots.

• Allow redeployment on another endpoint.

• Support both LAN and secure WAN access.

• Maintain security and domain integration.

Most importantly, the solution had to be repeatable.

Platform Overview.

Host System:

• Windows Server (Application Server).

• Joined to Active Directory (AD) domain.

• Docker Desktop installed.

• WSL2 enabled with Ubuntu.

Supporting Infrastructure.

• Domain Controller.

• Central File Server (SMB share).

• Internal LAN network.

• Cloudflare Zero Trust Tunnel for remote access.

Software Stack.

• Docker Desktop (WSL backend).

• Ubuntu 22.04 (WSL2).

• Immich (Docker containers).

• PostgreSQL (containerised).

• Redis compatible cache.

• Cloudflare Tunnel.

Prerequisites.

• Docker Desktop.

• Ubuntu 22.04.5 LTS, or another WSL distro.

• Nested virtualisation support (If you're using Hyper-V like me).

Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true

• Recommended system resources:

  • Memory: Minimum 6GB, recommended 8GB.

  • Processor: Minimum 2 cores, recommended 4 cores.

  • Storage: Recommended Unix-compatible filesystem (EXT4, XFS, ZFS, etc.) with support for user/group ownership and permissions.

Requirements | Immich

Why WSL and Docker Desktop.

Immich is designed for Linux. Rather than running it inside a traditional VM, Docker Desktop with WSL2 offers:

• A native Linux kernel.

• Direct container integration.

• Simplified networking.

• Reduced resource overhead.

With WSL integration enabled, Docker runs its engine inside Linux while remaining manageable from Windows.

Once enabled, Docker commands are available inside Ubuntu, confirming WSL can communicate with the Docker engine:

docker version

Preparing Network Storage.

To ensure data persistence, a shared folder was created on a file server:

\\FileServer\Immich

With subfolders:

library
upload
postgres
redis

SMB and NTFS permissions were restricted to authorised domain users, following least privilege principles.

Mounting The File Share In WSL.

Windows drive mappings do not appear inside WSL, as Linux requires its own SMB mount.

A directory was created to act as the mount target:

sudo mkdir -p /mnt/immich

At this stage, nothing is mounted. It is just an empty directory waiting to have something attached to it.

SMB mounting requires CIFS utilities as WSL doesn't include them by default:

sudo apt update
sudo apt install -y cifs-utils

With the mount point ready, I'll try mounting the share directly using my domain credentials:

sudo mount -t cifs //FileServer/Immich /mnt/immich \
-o username=DOMAIN\\ADUsername,vers=3.0,uid=1000,gid=1000

It failed instantly:

mount error(13): Permission denied

That error is vague, and does not tell you whether it is networking, DNS, firewall, or authentication.

So I'll check the kernel logs:

dmesg | tail -n 30

STATUS_LOGON_FAILURE

This tells us everything. The share is reachable, and the server responded, but authentication failed.

The problem is how the credentials are being passed. The corrected format is:

sudo mount -t cifs //FileServer/Immich /mnt/immich \
-o user=username,domain=ADDomain,vers=3.0,uid=1000,gid=1000,dir_mode=0770,file_mode=0660

Instead of embedding the domain in the username string, I'll split them properly.

• user= instead of username=DOMAIN\user .

• domain=ADDomain passed separately.

Verification:

ls -la /mnt/immich

And the expected folders were there.

Securing Credentials.

Rather than embedding Active Directory account credentials in scripts, I'll create a protected credentials file:

sudo nano /etc/cifs-immich.creds

Contents:

username=ADUsername
password=ADPassword

You don't need to put DOMAIN\ before the username, as we'll pass the domain separately in the mount options. It can work, but it's easy to mess up in Linux because backslashes are escape characters in some contexts... Also if the file is created with a heredoc or printf with the wrong quoting, you can end up with invisible characters that break auth. The kernel then returns a logon failure.

Permissions are restricted to ensure only root could read the file:

sudo chmod 600 /etc/cifs-immich.creds
sudo chown root:root /etc/cifs-immich.creds

Automounting the Share.

/etc/fstab is a plain text configuration that defines which disks and network shares Linux mounts automatically at startup. Adding the SMB share here ensures it is reconnected every time WSL starts, without requiring manual intervention.

In WSL2 environments, fstab processing is controlled by /etc/wsl.conf. If automounting is disabled, the file exists but is ignored.

In my case, only systemd needed to be enabled and fstab entries were processed automatically. However, if mounts do not persist, explicitly enabling automounting resolves most issues:

sudo nano /etc/wsl.conf

Example:

[boot]
systemd=true

[automount]
enabled = true
mountFsTab = true

To configure automatic mounting, edit /etc/fstab:

sudo nano /etc/fstab

Entry:

//FileServer/Immich /mnt/immich cifs credentials=/etc/cifs-immich.creds,domain=ADDomainName,vers=3.0,uid=1000,gid=1000,dir_mode=0770,file_mode=0660,nofail 0 0

The nofail option prevents boot delays if the file server is temporarily unavailable.

Verify the configuration:

sudo mount -a
mount | grep immich

Expected output: //FileServer/Immich on /mnt/immich type cifs (...)

By adding the SMB share to this file, the network storage is reconnected after every reboot, ensuring Docker and Immich always have access to persistent data.

Creating The Immich Project.

I'll create a dedicated project directory called immich:

mkdir -p ~/immich
cd ~/immich

Environment File.

The .env file defines storage and credentials:

UPLOAD_LOCATION=/mnt/immich/upload
DB_DATA_LOCATION=DBLocation
TZ=Europe/London
IMMICH_VERSION=v2
DB_PASSWORD=StrongPassword
DB_USERNAME=DBUsername
DB_DATABASE_NAME=immich

Key design decision:

• Media on SMB.

• Database stored locally in WSL.

PostgreSQL data directories should not be hosted on SMB shares. Network file systems introduce latency, unreliable file locking semantics, and caching behaviour that can cause corruption and transaction failures. Storing the database locally ensures correct POSIX locking and preserves data integrity.

A local database folder was created:

mkdir -p ~/immich/postgres

Docker Compose Configuration.

The official Immich compose file was used with volume overrides, binding persistent storage into containers:

- ${DB_DATA_LOCATION}:/var/lib/postgresql/data
- ${UPLOAD_LOCATION}:/usr/src/app/upload

Each service is configured with a restart policy:

restart: always

In a Docker compose file, this tells the Docker daemon to automatically restart that container if it exits or crashes, and to bring it back up after the Docker service starts (for example after a host reboot). The main exception is if you manually stop the container, in which case it stays stopped until you start it again.

Deploying The Stack.

Containers are pulled and started:

docker compose pull
docker compose up -d
docker compose ps

All services report healthy status:

Resolving Docker Credential Issues.

When pulling images, Docker failed with:

docker-credential-desktop.exe: exec format error

This occurs because WSL is attempting to use Windows credential helpers, so I'll remove them, forcing Docker to operate without incompatible helpers:

nano ~/.docker/config.json

Replace the contents with (or leave as blank):

{
  "auths": {}
}

Verifying Persistence.

The most important step is confirming that the database was not ephemeral.

Inside the Postgres container, run:

docker exec immich_postgres ls /var/lib/postgresql/data

The presence of PG_VERSION confirms initialisation.

Mount verification:

mount | grep /mnt/immich

Mount inspection:

docker inspect immich_postgres

This shows that the data directory is bound to persistent storage.

Networking and Access.

Docker publishes port 2283 to the host:

0.0.0.0:2283 → 2283

Let's create a Windows TCP port forwarding rule using the built in IP Helper service.

Retrieve the WSL instance IP address:

wsl hostname -I

$winIp = "<WINDOWS_SERVER_IP>"
$wslIp = "<WSL_IP>"

netsh interface portproxy add v4tov4 listenaddress=\(winIp listenport=2283 connectaddress=\)wslIp connectport=2283

Portproxy rules are stored in the registry under:

HKLM\SYSTEM\CurrentControlSet\Services\PortProxy\v4tov4\tcp

We can also confirm that this rule is present with:

C:\Windows\System32>netsh interface portproxy show all

Listen on ipv4:             Connect to ipv4:

Address         Port        Address         Port
--------------- ----------  --------------- ----------
10.0.0.XXX      2283        172.XX.XXX.XX   2283

I now need to create a Windows firewall rule to allow TCP port 2283, which can be achieved with the following PowerShell command:

New-NetFirewallRule -DisplayName "Immich TCP 2283"
-Direction Inbound -Protocol TCP -LocalPort 2283 -Action Allow

We can also use the following command to see if netstat shows a listener on 10.0.0.<your-server-ip>:2283 or 0.0.0.0:2283, to see if anything is exposed to the LAN.

Test-NetConnection -ComputerName 10.0.0.X -Port 2283
netstat -ano | findstr :2283

PS C:\WINDOWS\system32> Test-NetConnection -ComputerName 10.0.0.0 -Port 2283

ComputerName     : 10.0.0.0
RemoteAddress    : 10.0.0.0
RemotePort       : 2283
InterfaceAlias   : Ethernet 3
SourceAddress    : 10.0.0.0
TcpTestSucceeded : True

PS C:\WINDOWS\system32> netstat -ano | findstr :2283
  TCP    0.0.0.0:2283           0.0.0.0:0              LISTENING       12276
  TCP    10.0.0.0:53504         10.0.0.0:2283          TIME_WAIT       0
  TCP    10.0.0.0:60657         10.0.0.0:2283          TIME_WAIT       0
  TCP    [::]:2283              [::]:0                 LISTENING       12276
  TCP    [::1]:2283             [::]:0                 LISTENING       4672

Immich then becomes accessible on:

http://server-ip:2283

WSL Networking Architecture.

WSL operates behind a Hyper-V NAT interface:

• Internal subnet: 172.x.x.x.

• Host bridges traffic.

• Docker Desktop handles forwarding.

In this deployment, manual portproxy rules were required because Docker Desktop was not exposing container ports directly to the Windows host network.

Although the server was configured with only a single Hyper-V virtual network adapter connected to the external vSwitch, the system presents multiple logical network interfaces once WSL and Docker Desktop are installed.

From a Hyper-V perspective, the virtual machine has one primary adapter attached to the external switch, which provides normal LAN connectivity. This adapter is assigned an address via DHCP from the gateway, and handles domain access, DNS resolution, internet access, and communication with other servers on the network.

Alongside this, a second virtual adapter appears:

vEthernet (WSL (Hyper-V firewall)) with an address in the 172.28.128.0/20 range.

This adapter is not connected to the external vSwitch and is not manually created. It is automatically generated by WSL2 when the Linux subsystem is enabled. Internally, WSL runs inside a lightweight Hyper-V virtual machine. To allow Windows and Linux to communicate, Hyper-V creates a private NAT network between the host and the WSL VM.

This network operates as follows:

• WSL runs on an isolated internal subnet, typically in the 172.x.x.x private address range.

• Windows acts as the gateway and NAT device for this subnet.

• Traffic from WSL is translated and forwarded through the main 10.0.0.0/24 interface.

• Inbound traffic must be explicitly forwarded.

The 172.28.128.1 address therefore belongs to the Windows host side of the WSL virtual switch. The Linux environment sits behind it on the same subnet. This is why no default gateway is shown on that interface. It is not intended for external routing.

Importantly, this network is created and managed entirely by WSL and Hyper-V. It does not appear as a separate vSwitch in Hyper-V Manager because it is implemented as an internal virtual switch owned by the WSL platform.

Docker Desktop builds on top of this architecture. Containers run inside the WSL VM and inherit this private NAT network. As a result, container services are bound to the 172.x.x.x subnet by default, not directly to the server’s 10.0.0.0/24 interface.

In theory, Docker Desktop should automatically publish container ports to the Windows host and forward them to the external network. In practice, this forwarding was unreliable in this environment. Services were reachable from inside WSL but not consistently accessible from the LAN.

Because of this, manual portproxy rules were implemented on Windows to bridge traffic between the external interface and the WSL subnet. These rules explicitly forward connections from 10.0.0.XX to the relevant 172.28.x.x container addresses.

This design means that, despite appearing to have multiple “network adapters”, the system is still built around a single physical path to the network. The 10.0.0.0/24 adapter provides real connectivity, while the 172.28.0.0/20 adapter exists purely to support WSL and container isolation.

Understanding this separation was essential when diagnosing connectivity issues, firewall behaviour, and port publishing failures during deployment.

Secure WAN Access with Cloudflare Tunnel & Conditional Access.

For remote access, a Cloudflare Zero Trust Tunnel was optionally configured.

High-level architecture:

Internet → Cloudflare → Tunnel → App Server → Immich

Advantages:

• No open inbound ports.

• Zero Trust Authentication).

• TLS encryption.

• Single Sign-On (SSO).

• DDoS protection.

This provided secure external access without exposing the server.

We can also create Conditional Access policies to govern access to Cloudflare's Zero Trust Network, such as enforce compliance requirements, set browser controls and sign-in frequency or token persistence, and block access based on signals during sign-in.

Best Practices Applied.

Security.

• Domain authentication.

• Restricted SMB permissions.

• Encrypted credentials.

• No anonymous access.

• Firewall hardening.

Reliability.

• Local database storage.

• Automatic restarts.

• Persistent mounts.

• Health checks.

Maintainability.

• Versioned configuration.

• Centralised storage.

• Reproducible structure.

• Documented procedures.

Known Limitations.

Despite the success, several limitations remain:

1. WSL mounts depend on network availability.

2. Docker Desktop is a dependency.

In a production environment, you would install docker in a Linux VM directly, rather than use Docker Desktop.

1. Postgres backups are manual by default.

2. Requires domain connectivity.

3. SMB latency can affect performance.

These are acceptable trade-offs in my environment :)

Backup Strategy.

A simple database backup:

docker exec immich_postgres pg_dump -U postgres immich > /mnt/immich/backups/db.sql

Restore example:

docker exec -i immich_postgres psql -U postgres immich < /mnt/immich/backups/db.sql

Verify backup integrity:

ls -lh /mnt/immich/backups/db.sql

• Media is already stored on the file server.

• Backups can be automated with cron.

Verification Commands.

These commands can be used at any time to validate the deployment.

Mount status:

mount | grep immich

Credentials:

sudo ls -l /etc/cifs-immich.creds

fstab:

grep immich /etc/fstab

Containers:

docker compose ps

Database integrity:

docker exec immich_postgres test -f /var/lib/postgresql/data/PG_VERSION && echo OK

Firewall:

Get-NetFirewallRule | Where DisplayName -Like "*Immich*"

Failover Testing.

To validate resilience, the following failure scenarios should be tested:

1. Restart WSL:

wsl --shutdown

1. Restart Docker:

Restart-Service com.docker.service

1. Reboot the host server.

2. Post recovery validation:

docker compose ps
mount | grep immich

All services and mounts should reinitialise automatically.

Conclusion.

This deployment demonstrates that it is entirely possible to run a reliable, persistent, Linux-first application on Windows Server using Docker and WSL.

By combining:

• Domain authentication.

• SMB-backed media storage.

• Localised database persistence.

• Container orchestration.

• Secure networking.

It is possible to achieve an enterprise-grade deployment using largely open-source tooling.

The key lesson is that persistence is not automatic. It must be deliberately designed. Once storage, authentication, and mounts are correct, containers become highly resilient and portable.

This approach provides a strong foundation for self-hosted services in mixed Windows and Linux environments.

docker-compose.yml

#
# WARNING: To install Immich, follow our guide: https://docs.immich.app/install/docker-compose
#
# Make sure to use the docker-compose.yml of the current release:
#
# https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml
#
# The compose file on main may not be compatible with the latest release.

name: immich

services:
  immich-server:
    container_name: immich_server
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    # extends:
    #   file: hwaccel.transcoding.yml
    #   service: cpu # set to one of [nvenc, quicksync, rkmpp, vaapi, vaapi-wsl] for accelerated transcoding
    volumes:
      # Do not edit the next line. If you want to change the media storage location on your system, edit the value of UPLOAD_LOCATION in the .env file
      - ${UPLOAD_LOCATION}:/data
      - /etc/localtime:/etc/localtime:ro
    env_file:
      - .env
    ports:
      - '2283:2283'
    depends_on:
      - redis
      - database
    restart: always
    healthcheck:
      disable: false

  immich-machine-learning:
    container_name: immich_machine_learning
    # For hardware acceleration, add one of -[armnn, cuda, rocm, openvino, rknn] to the image tag.
    # Example tag: ${IMMICH_VERSION:-release}-cuda
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}
    # extends: # uncomment this section for hardware acceleration - see https://docs.immich.app/features/ml-hardware-acceleration
    #   file: hwaccel.ml.yml
    #   service: cpu # set to one of [armnn, cuda, rocm, openvino, openvino-wsl, rknn] for accelerated inference - use the `-wsl` version for WSL2 where applicable
    volumes:
      - model-cache:/cache
    env_file:
      - .env
    restart: always
    healthcheck:
      disable: false

  redis:
    container_name: immich_redis
    image: docker.io/valkey/valkey:9@sha256:546304417feac0874c3dd576e0952c6bb8f06bb4093ea0c9ca303c73cf458f63
    healthcheck:
      test: redis-cli ping || exit 1
    restart: always

  database:
    container_name: immich_postgres
    image: ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0@sha256:bcf63357191b76a916ae5eb93464d65c07511da41e3bf7a8416db519b40b1c23
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_DB: ${DB_DATABASE_NAME}
      POSTGRES_INITDB_ARGS: '--data-checksums'
      # Uncomment the DB_STORAGE_TYPE: 'HDD' var if your database isn't stored on SSDs
      # DB_STORAGE_TYPE: 'HDD'
    volumes:
      # Do not edit the next line. If you want to change the database storage location on your system, edit the value of DB_DATA_LOCATION in the .env file
      - ${DB_DATA_LOCATION}:/var/lib/postgresql/data
    shm_size: 128mb
    restart: always
    healthcheck:
      disable: false

volumes:
  model-cache:

ClickFix, sometimes described as “fake CAPTCHA” execution, is a social engineering technique where the attacker deliberately moves the critical step of the intrusion onto the user.

Instead of exploiting a vulnerability automatically, the attacker convinces the victim to run the payload themselves, most commonly by opening the Windows Run dialog and pasting a command presented as a “verification” step.

This user driven execution is a large part of why ClickFix has been effective against organisations with otherwise mature controls.

What ClickFix actually is.

At a high level, ClickFix is an interaction pattern, not a single malware family. The attacker’s objective is to get a user to perform a sequence of actions that results in code execution under the user’s context. The lure is usually presented as a familiar web experience such as a CAPTCHA prompt, an “I am not a robot” verification, or a fake error banner that claims a quick manual fix is required.

ClickFix is described as an attack chain that commonly begins with phishing, malvertising, or a compromised website, then leads the user to a visual lure that instructs them to run a command, specifically because that user interaction can bypass some conventional automated detections.

Why it works so well.

ClickFix succeeds because it exploits normal problem solving behaviour. The page looks like a legitimate friction point that users are conditioned to complete quickly, and the instructions are presented in a “helpdesk style” voice that implies compliance is routine.

Technically, it also shifts the attacker’s risk. If the user runs the command, the execution often happens in a way that looks like legitimate administrative activity, especially in environments where PowerShell is widely used and script execution is not tightly controlled.

The ClickFix Execution Pathway In Windows.

Although the exact payload varies, many ClickFix chains have a similar structure:

The site presents a prompt that encourages a copy and paste action. The copied content is a command, or a small “stager” that pulls the real payload from the internet. This is frequently designed to blend in with normal Windows tooling, using legitimate signed binaries that can execute script content.

In real incidents, you’ll often see execution via PowerShell, cmd, rundll32, or mshta. mshta is particularly notable because it is a Windows native binary designed to execute HTA script content and has been repeatedly abused as an execution proxy.

Once the initial command runs, typical next steps depend on the operator and payload, but commonly include downloading a second stage, establishing persistence, credential access, browser data harvesting, and then lateral movement or cloud pivoting where possible.

Detection.

RunMRU (Most Recently Used).

RunMRU (Most Recently Used) is a Windows registry key that stores a list of the last 26 commands entered in the Run dialog (Win + R) on a per-user basis. The command’s execution order can be obtained from the “MRUList” value in the key. It keeps an ordered list (left being most recent) of recently used commands (hence the name MRU).

To confirm whether code was actually entered and executed into Run, you can check Run history in the registry:

NTUSER.dat\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RunMRU

Review the most recent entries. If they followed the prompt, you will typically see something like PowerShell, cmd, mshta, rundll32, or a base64 encoded one liner recorded there. If you are logged in as the user:

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU

If you are inspecting another profile, load NTUSER.dat and check:

HKU\<SID>\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU

This is useful because it shows what was entered, not just what was clicked in the browser. The MRUList (REG_SZ) string tells you the order in which the commands were entered.

If you do see a malicious record, treat this as one input, not the conclusion. You still need to tie it to process execution, network activity, and post execution actions to understand impact.

What To Expect After Execution.

If you are investigating a suspected ClickFix event, it helps to think in terms of what an operator needs immediately after they land:

They need reliability, so they often use short stagers and then pull the rest from the network.

They need stealth, so they often use built in tooling and reduce on disk footprint.

They need access, so they will frequently attempt credential theft, token theft, or session hijacking, especially if the user has privileged access.

This is why a ClickFix investigation should not stop at “did something run”. The deeper question is what access was gained, what was touched, and what capability was established afterwards.

Investigation.

Step 1: Establish scope and time boundaries.

Start with time anchoring. Determine when the user saw the prompt, when they took the action, and what device they used. If you have EDR, this becomes an initial timeline exercise: browser process, clipboard related activity if available, then the first suspicious child process and any outbound connections that follow.

Where possible, treat this as an incident until you can prove otherwise. ClickFix is designed to create uncertainty and urgency.

Step 2: Identify the first execution and the parent chain.

The most useful early signal is the process tree. You are looking for an unusual transition from a user initiated action into a scripting or execution host.

In many environments, you will see one of two patterns:

• A browser process that leads quickly into script execution via a Windows binary.

• A user opened execution path such as the Run dialog followed by a scripting host.

At this stage, capture command line arguments, parent process, network connections, and any spawned child processes. This is where you often find the “stager” that reveals the next infrastructure and payload stage.

Step 3: Collect endpoint evidence that reflects user driven execution.

This is where Windows artefacts matter. You want artefacts that record what the user actually typed or pasted, rather than what the browser displayed.

Step 4: Hunt for follow on behaviours, not just the first command.

Once you identify the first execution, pivot into “what changed” and “what persisted”.

Look for new scheduled tasks, new services, unusual registry autoruns, newly dropped executables in user writeable locations, unusual PowerShell usage patterns, and outbound connections to new domains or IPs. If your EDR supports it, hunt for unusual child processes of common scripting hosts.

If mshta is present in the chain, treat it as higher risk because it can execute script content embedded in HTML and is frequently used as a proxy for code execution.

Step 5: Expand to identity and cloud where applicable.

ClickFix is often the first step, not the final objective. If the compromised user has access to Microsoft 365 or other SaaS platforms, you should treat identity as in scope immediately.

This typically means reviewing sign in activity, risky sign ins if you have them, unusual OAuth consent grants, mailbox rules, forwarding changes, unusual file sharing activity, and new devices or tokens. The exact telemetry depends on your stack, but the principle is consistent: verify whether the attacker converted endpoint execution into durable access elsewhere.

Responding to an attack.

A solid ClickFix response usually needs to cover containment, credential and session hygiene, eradication, and resilience.

Containment should focus on isolating the affected endpoint and limiting further outbound access where feasible, especially if you have evidence of a live second stage.

Credential and session hygiene should assume the user context is compromised. Password reset alone may not be sufficient if tokens were captured, so you should revoke sessions where your identity platform allows it and ensure privileged access is reviewed.

Eradication should remove persistence mechanisms, remediate dropped binaries, and validate that the initial execution vector is no longer present.

Resilience should include closing the specific execution pathways and tightening controls that make ClickFix succeed in the first place.

Prevention Controls That Meaningfully Reduce ClickFix Risk.

ClickFix relies heavily on built in tools being available for arbitrary execution. The most effective prevention work therefore tends to reduce easy execution paths and strengthen detection where you cannot remove them.

Microsoft Defender for Endpoint Attack Surface Reduction rules are a strong baseline in many Windows estates, especially where Office based initial access is common. These rules are documented and can block common child process creation patterns that attackers rely on.

Beyond ASR, consider application control approaches such as allow listing for scripting hosts, restrictions on LOLBins that are rarely used in your organisation, and tighter PowerShell governance through logging, constrained execution, and script signing where it is practical. Pair this with web filtering, stronger browser controls, and user education that explicitly calls out the “copy and paste a verification command” pattern.

The important point is that ClickFix is not beaten by a single setting. It is reduced by layered friction: fewer execution paths, stronger visibility, and faster containment when the tactic slips through.

You could also consider blocking the Run Dialog for end users, if it isn’t needed.

Closing Thoughts.

ClickFix is a reminder that some of the most damaging intrusions still begin with persuasion, not exploitation. If your investigation approach centres on process trees, endpoint artefacts, and follow on behaviours, you can move from uncertainty to clarity quickly, and you can shape controls that make the tactic far less reliable for attackers.

Prerequisites.

Join types.

LAPS is only supported on:

• Microsoft Entra joined devices.

• Microsoft Entra hybrid joined devices.

Microsoft Entra registered devices are not supported.

License requirements.

LAPS is available to all customers with Microsoft Entra ID Free or higher licenses. Other related features like administrative units, custom roles, Conditional Access, and Intune have other licensing requirements.

Required roles and permissions.

Other than the built-in Microsoft Entra roles like Cloud Device Administrator and Intune Administrator that are granted device.LocalCredentials.Read.All, you can use Microsoft Entra custom roles or administrative units to authorise local administrator password recovery.

Enabling Windows LAPS Within Microsoft Entra ID.

To enable Windows LAPS with Microsoft Entra ID, you must take actions in Microsoft Entra ID and the devices you wish to manage. We recommend organizations manage Windows LAPS using Microsoft Intune. If your devices are Microsoft Entra joined but not using or don't support Microsoft Intune, you can deploy Windows LAPS for Microsoft Entra ID manually. For more information, see the article Configure Windows LAPS policy settings.

1. Sign in to the Microsoft Entra admin center as at least a Cloud Device Administrator.

2. Navigate to Entra ID > Devices > Overview > Device Settings.

3. Select Yes for the Enable Local Administrator Password Solution (LAPS) setting, then select Save. You might also use the Microsoft Graph API Update deviceRegistrationPolicy to complete this task.

Deploying Windows LAPS Using Microsoft Intune.

Ensure the prerequisites for Intune to support Windows LAPS in your tenant are met before creating policies. Intune's LAPS policies don't create new accounts or passwords. Instead, they manage an account that's already on the device.

1. Sign in to the Microsoft Intune admin center and go to Endpoint security > Account protection, and then select Create policy.

2. Set the Platform to Windows, Profile to Local admin password solution (Windows LAPS), and then select Create.

Monitoring LAPS Password Access Via Microsoft Sentinel/Defender XDR.

References.

Use Windows Local Administrator Password Solution (LAPS) with Microsoft Entra ID - Microsoft Entra ID | Microsoft Learn

Deploy Intune policies to manage Windows LAPS - Microsoft Intune | Microsoft Learn

A SOC investigation following a compromised user typically takes between 45 minutes and 3 hours, depending on the volume of user activity, the quality of available audit data, the complexity of the attacker’s behaviour and whether any signs of exfiltration or mailbox manipulation require deeper analysis.

Straightforward cases involving a single suspicious sign-in and minimal follow-on activity usually sit at the lower end of that range, while incidents involving large-scale data access, unusual file-sharing behaviour or signs of targeted exfiltration take longer because they raise concerns around compliance, data sensitivity, regulatory obligations and potential security impact.

Initial Alert & Triage.

Containment and Identity Recovery.

Sign-In Timeline Reconstruction.

Mailbox and Exchange Online Forensics.

SharePoint, OneDrive, and Exfiltration Overview.

OAuth Application and Token Misuse Assessment.

Defender Signals and Endpoint Correlation.

Impact Assessment and Compliance Review.

Remediation, Hardening and Closure.

Level is a lightweight remote monitoring and management platform for Windows devices. It can be deployed manually, although most organisations prefer to automate installation through device management tooling.

This article explains how to deploy the Level agent using a Microsoft Intune platform script. This approach provides a reliable and centrally managed installation path and ensures that devices are onboarded in a predictable way.

The method described here is suitable for both small scale and full fleet rollouts and is one of the simplest ways to ensure that the Level agent installs silently without user interaction.

Understanding The Level Silent Installer.

Before creating the script, it is important to understand what the Level silent installer does. Level generates an API key which is included in the installation arguments. This key does not provide administrative access to the Level platform. It is used only to enroll the device during installation.

Once the device is enrolled, the key has no further active purpose unless it is reused elsewhere.

The installer file is downloaded from Level directly and is executed by the script on the target device. Intune then reports the success or failure of the script to assist with troubleshooting.

For example:

$args = "LEVEL_API_KEY=XXXXXXXXXXXXXXXXXXXXXXXX";
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12;
$tempFile = Join-Path ([System.IO.Path]::GetTempPath()) "level.msi";
$ProgressPreference = 'SilentlyContinue'; Invoke-WebRequest -Uri "https://downloads.level.io/level.msi" -OutFile $tempFile; $ProgressPreference =
'Continue'; Start-Process msiexec.exe -Wait -ArgumentList "/i `"$tempFile`" $args /qn";

This script instructs the device to download the Level MSI installer from the Level content delivery network using TLS version 1.2 in order to ensure a secure connection. The file is written to the system’s temporary directory and then executed through msiexec as a completely silent installation using the /qn switch.

Creating The Platform Script.

1. Sign in to the Level RMM platform and copy the silent install command for windows. This will look something like the following:

   1.    $args = "LEVEL_API_KEY=XXXXXXXXXXXXXXXXXXXXXXXX"; [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12; $tempFile = Join-Path ([System.IO.Path]::GetTempPath()) "level.msi"; $ProgressPreference = 'SilentlyContinue'; Invoke-WebRequest -Uri "https://downloads.level.io/level.msi" -OutFile $tempFile; $ProgressPreference = 'Continue'; Start-Process msiexec.exe -Wait -ArgumentList "/i `"$tempFile`" $args /qn";
      

   2. 

2. Create a .ps1 file, paste the silent install command obtained in step 1and save the file. You will need to upload this file to Microsoft Intune in step 7.

3. Sign in to the Microsoft Intune admin center and go to Devices > Scripts and remediations > Platform scripts.

4. Select Add, then Windows 10 and later.

5. Provide a name and description for the script, and choose Next.

6. On the Script settings blade;

   1. Set Run this script using the logged on credentials to No.

   2. Set Enforce script signature check to No.

   3. Set Run script in 64 bit PowerShell Host to No.

7. Upload the Level RMM PowerShell script.

8. Select Next.

9. Specify the assignments and choose next. It is recommended to create a dedicated device group for any devices that will be onboarded to Level so the Level agent can be deployed in a controlled and predictable manner.

10. Select Create.

Post Deployment Verification.

Once the script has been assigned and devices begin to check in, Intune will report whether the script executed successfully. You can review results within the Platform script view in the Intune portal.

You should also sign in to the Level dashboard to confirm that newly onboarded devices appear as expected. After a few minutes each device should report its status, policies should apply and the agent should begin sending telemetry.

If you want a higher level of assurance, you can also create a remediation script within Intune that checks for the presence of the Level service and confirms that the installation has not been removed or disrupted. This can help detect devices where users or third party software have interfered with the agent.

Attack Simulation Training is a feature of Microsoft Defender for Office 365 (available with a Defender for Office Plan 2 license) that.

Launching An Attack Simulation.

Prerequisites.

• Microsoft Defender for Office 365 (MDO) Plan 2 license.

To launch a simulated phishing attack, perform the following steps:

1. Navigate to the Microsoft Defender portal → Email & collaboration → Attack simulation training → Simulations.

2. Select Launch a simulation.

3. Choose the technique you’d like to use.

The available options are:

• Credential harvest.

• Malware Attachment.

• Link in Attachment.

• Link to Malware.

• Drive-by URL.

• OAuth Consent Grant.

• How-to Guide.

In this example, I am going to use the technique Malware Attachment. With this technique, a malicious actor creates a message, with an attachment added to the message. When the target opens the attachment, typically some arbitrary code such as a macro will execute in order to help the attacker install additional code on a target's device, or further entrench themselves.

MITRE Reference: Phishing: Spearphishing Attachment, Sub-technique T1566.001 - Enterprise | MITRE ATT&CK®

Once you have chosen the technique you’d like to use:

1. Enter a simulation name. In this example, I will name it AST_AllUsers_MalwareAttachment.

2. Enter a description (optional).

3. Select Next.

4. Choose the payload name. I will use DocuSign Shared Document, which has a compromise rate of 27.23%, but it’s recommended that you choose a payload that you believe will have the highest compromise rate.

4. Send a test email (recommended). Selecting this option will save and send the selected payload to the currently logged in user for formatting validation. It will not be included in any simulation reporting and will not work as part of an end to end simulation scenario.

5. Select Next.

6. On the “Target users” blade, add existing users and groups or import a list of email addresses. In this example, I will only select my own user object.

7. Select Next.

8. Choose whether you’d like to exclude users or groups from this campaign, and select Next.

9. Select training preferences, assignment, and customise a landing page for this simulation. In this example, I will use Assign training for me (Recommended), and 30 days after Simulation ends as the training due date.

8. Select Next.

9. Choose a Phish landing page. A landing page provides a learning moment to the user after getting phished. In this example, I will use Microsoft Landing Page Template 4, which looks like the following:

10. Choose Next.

11. Select end user notification preferences for this campaign. I will use Microsoft default notifications (recommended), but you may wish to either not deliver notifications or use custom end user notifications. In this example, I will set the delivery preference to Deliver during simulation, however it may be more appropriate to deliver this notification after the simulation has completed, as doing so reduces the likelihood of users alerting one another while it is in progress. I will also set the training reminder notification to Twice a week.

12. Select Next.

13. On the “Launch details” blade, specify when the simulation should start and whether the payloads should be removed from user inboxes. You can schedule the launch up to a maximum of 14 days in advance, and set the simulation to end after any period between 2 and 30 days. In this example, I will Launch this simulation as soon as I’m done, and configure the simulation to end after 21 days.

14. Specify whether you’d like to enable `region aware timezone delivery.

Region aware delivery uses the mailbox time zone of each targeted user to decide when the message should be delivered. Delivery can vary by about one hour either side depending on the user’s time zone.

For example:

At 07:00 GMT, an administrator creates and schedules a campaign to start at 09:00 GMT on the same day.
User A’s mailbox is set to UTC+3.
User B’s mailbox is set to GMT (UTC+0).

At 09:00 GMT, the simulation message is delivered to UserB. With region aware delivery enabled, the message is not sent to UserA at this time, because 09:00 GMT is 12:00 in UserA’s time zone. Instead, the message is sent to UserA at 09:00 in their own time zone on the following day.

This means the campaign may initially look as if it has only delivered to users in one region. As time progresses and users in other time zones reach the scheduled delivery time, the number of targeted users increases.

If region aware delivery is disabled, the campaign follows the organiser’s time zone and all users receive the message at the same GMT time.

15. Select Next.

16. Finally, review your Simulation information before you launch it. If you followed along with me, your simulation review should look like the below:

Delivery Platform
Email

Technique
Malware Attachment

Name
AST_AllUsers_MalwareAttachment

Payloads
DocuSign Shared Document

Target Users
1 targeted users or groups
0 users or groups excluded

17. Select Submit.

18. Next, Go to Attack simulation training overview, or View all payloads.

Note: this simulation launched near instantly. I scheduled the simulation at 18:33:34 and received the email in my inbox at 18:35:00, from the sender notificationsrelyadmin@bankmenia.org (DocuSign Info).

The Result:

Attack Simulation Training.

Attack Simulation Trainings helps you assess phishing risk, train users, and evaluate their progress through an intelligent phishing risk reduction tool.

Security trainings are the best in class trainings made available by Microsoft for you to train your professionals about security and compliance of your organisation and help in improving their behaviour to common attacks and rules.

Training campaigns can be run to train your employees on topics including security, compliance, privacy, or social engineering risks.

To create a training campaign:

1. Navigate to the Microsoft Defender portal → Email & collaboration → Attack simulation training → Training.

2. Select Create new.

3. Enter a training name. In this example, I will name it AST_AllUsers_AllTraining.

4. Enter a description (optional).

5. Select Next.

6. Add existing users and groups or import a list of email addresses.

7. Select Next.

8. Choose users or groups to be excluded from this campaign.

9. Select Next.

10. Select training modules.

Below is the list of all available trainings that you can use to run a campaign or a simulation:

Social Engineering and Phishing.

• Social engineering via email

• Insider Threats

• Identity theft – Example of an attack

• Real or not real? How deep is the fake?

• Computer Compromise

• C-Level email impersonation

• AI: Helpful tool or threat?

• Credential Theft

• Browser-in-the-browser attack

• Application account compromise

• Unintentional Insider Threat

• Sharing an organisation’s computer

• Risky USB

• Phishing by Phone

• Handling Unidentified Individuals

• Friend or Foe?

• Working Remotely

• Travelling Securely

• The Clean Desk Principle

• Mobile Devices

• Secure sharing of sensitive information

• Spear Phishing

• Mass-marketing phishing

• Business Email Compromise (BEC)

• Phishing websites

• How to report suspicious messages

• Spoofing: how to avoid falling victim

Malware, Ransomware and Technical Threats.

• Ransomware

• Malicious Software

• Cyber Fraud

• Cyber Attack Detection

• Malicious digital QR codes

• Malicious printed QR codes

• Risks associated with file transfer

Data Protection, Privacy and Compliance

• Privacy Awareness

• GDPR Essentials

• CCPA Essentials

• Personally Identifiable Information (PII)

• Protected Health Information (PHI)

• HIPAA/HITECH

• Protecting your information from Wi-Fi security risks

• Protecting Sensitive Information – Information Handling

• Preventing Security Breaches

• Countering Misinformation

• Identity Theft

• Financial Data Exposure

• Employee Data Breach

• Importance of Security Culture in the Organisation

• Personal Information Protection and Electronic Documents Act

• PCI DSS for Call Centres

• PCI DSS for Retailers

• PCI DSS Awareness

• PCI DSS Awareness

• AI risks and best practices

• Control de acceso

• Understanding app consent requests

• OAuth Consent Grant

Physical Security and Behavioural Security

• How to be security aware

• Applying the Clean Desk Principle

• Access Control

• Responsible Use of the Internet

• Protecting Payment Card Data

• Physical Security

• Smartphones

• Intellectual Property

• Information Lifecycle

• Information Classification

• Incident Reporting

Cloud, Internet and IT Usage.

• Cloud Services

• Cloud Computing

• Bring Your Own Device (BYOD)

• Open Wi-Fi Risks

• Open Web Application Security Project (OWASP) Top 10

Other Awareness Topics

• Privacy

• Passwords

11. Select Next.

12. Select end user notification preferences for this campaign. This can be either Microsoft curated end-user notifications (recommended), or customised end-user notifications. In this example, I will choose Microsoft default notification (recommended), and I will also set the delivery preference of Microsoft default training only campaign-training reminder notification to Twice a week.

13. Select Next.

14. Select the launch and end date and time for your training campaign. You can schedule it up to 14 days in advance, and the end date can be configured to 30 days from the launch date. In this example, I will launch the training as soon as I’m done, and end the campaign 30 days later.

15. Select Next.

16. Review your training campaign information before you launch it.

For example:

Name
AST_AllUsers_AllTraining

Description

Selected users
1 users selected

Training Campaign Content
108 trainings
910 mins 0 sec total duration

Introduction to Information Security
Business Email Compromise
Email
Identity Theft
Malware
Phishing
Ransomware
Social Engineering
Anatomy of a Spear Phishing Attack
Phishing websites
Ransomware
...

Schedule campaign
Scheduled to launch after submission
Scheduled to end on 15/12/2025, 20:00:00

17. Select Submit.

End users can select Go to training from within the email to start their training.

Third Party Phishing Simulations.

Phishing simulations are attacks orchestrated by your security team and used for training and learning. Simulations can help identify vulnerable users and lessen the impact of malicious attacks on your organisation.

Third-party phishing simulations require at least one Sending domain entry [source domain or DKIM] AND at least one Sending IP entry to ensure message delivery. URLs present in the email message body will also be automatically allowed at time of click as a part of this phishing simulation system allow.

Note: The Simulation URLs to allow field is optional and available for non-email based phishing simulation campaign scenarios. Specifying URLs in this field ensures that these URLs aren't blocked at time of click for phishing simulation scenarios that use Microsoft Teams and Office apps (Word, Excel, etc).

To configure the advanced delivery of IP addresses, sender domains and URLs that are used as part of your 3rd party phishing simulation:

• Navigate to Microsoft Defender → Email & collaboration → Policies & rules → Threat policies → Advanced delivery → Phishing simulation.

Final Thoughts On Attack Simulation Training Within Microsoft Defender for Office 365 (MDO).

The training component within Microsoft Defender for Office 365 is one of the strongest elements of the platform. The content is clear, structured and delivered at an appropriate pace, which makes it suitable for a broad range of end users.

The videos are concise, focused on real behaviours, and avoid unnecessary detail while still offering technically accurate guidance. They reinforce the essential principles of identifying suspicious messages, reporting them correctly and understanding how common attack techniques work in practice.

End users cannot skip ahead or jump past sections they have not viewed. They may pause and rewind, but they can only return to points they have already watched.

For organisations seeking measurable improvements in user behaviour, this structured delivery model aligns well with security awareness best practice recommended by Microsoft and the National Cyber Security Centre.

Overall, the training within MDO complements attack simulations effectively. It reinforces learning rather than relying solely on pass or fail outcomes, and it encourages users to understand the reasoning behind safe email handling rather than memorising steps. When used consistently, it provides a measurable uplift in user readiness and reduces the likelihood of successful social engineering attacks.

If your organisation uses Microsoft 365 heavily and has Defender for Office 365 Plan 2 available, I would highly recommend giving Attack Simulation Training a try!

References.

Reference: Simulate a phishing attack with Attack simulation training - Microsoft Defender for Office 365 | Microsoft Learn

Reference: Landing pages in Attack simulation training - Microsoft Defender for Office 365 | Microsoft Learn.

Reference: Attack Simulation Training With Microsoft | YouTube.

Training campaigns in Attack simulation training - Microsoft Defender for Office 365 | Microsoft Learn

Refer to this if you’d like to assign training to users without putting them through a simulation.

Reference: Get started using Attack simulation training - Microsoft Defender for Office 365 | Microsoft Learn

Refer to this for creating training campaigns.

Reference: Configure the advanced delivery policy for non-Microsoft phishing simulations and email delivery to SecOps mailboxes - Microsoft Defender for Office 365 | Microsoft Learn

Enjoyed this article? Consider reading: Bypassing Microsoft Intune Compliant Device Conditional Access Requirements Using TokenSmith.

When managing identity security in Microsoft Entra ID, having clear visibility into which multi-factor authentication (MFA) methods users have registered is essential.

It underpins compliance, user assurance, and incident response.

Entra ID’s portal presents a convenient, current-state view of a user’s authentication methods. It is useful for spot checks but it is not designed for tenant-wide assurance, forensic context, or durable compliance evidence.

Microsoft Sentinel’s native identity tables focus on events such as sign-ins and administrative changes, not on the underlying configuration state of which methods each user has registered. The authoritative source for that configuration is Microsoft Graph’s authentication methods API.

The most reliable pattern is to collect from Graph on a schedule, normalise the results, and write into a custom Sentinel table that you can query with KQL for audits and investigations.

Microsoft Sentinel can ingest valuable identity telemetry, SignInLogs, AuditLogs, and risk detections, but these sources do not reveal which MFA methods each account has configured.

Why You Need Real MFA Visibility.

Having visibility of which authentication methods users have registered in Microsoft Entra ID is invaluable for identity assurance, compliance, and operational monitoring. It is not enough to know that multi-factor authentication (MFA) is enforced. You need to know which authentication methods each user has actually registered.

Entra’s native tools, such as the Authentication Methods dashboard and the IdentityInfo table in Microsoft Sentinel give only a partial picture. The IdentityInfo table provides a Boolean flag (“registered / not registered”), and while AuditLogs can record when an MFA method is added or removed, neither provides the full configuration-level detail of which methods are actually present on each account.

That limitation makes it impossible to answer questions such as:

• Which users still rely solely on passwords?

• How many FIDO2 keys or Authenticator apps are deployed?

• Are any users using outdated or duplicate devices?

• Can we prove our MFA rollout for audit or compliance evidence?

To obtain a complete, historical, and queryable record of authentication methods, we must pull data directly from the Microsoft Graph API and store it where it can be queried and correlated: Microsoft Sentinel.

Where Entra Falls Short.

Native UI: Authentication Methods Reporting

The User Registration Details view under Identity → Authentication methods in the Entra Admin Centre provides useful at-a-glance information but is limited:

• It displays only current state, with no history.

• Phone numbers and device names are masked for privacy.

• There is no export or filtering beyond basic search.

• It cannot answer questions like “Which users have registered both Authenticator and FIDO2?”

Sentinel’s Built-in Tables

When diagnostic settings are connected, Sentinel receives the following data streams from Entra ID:

These tables are designed for behavioural analysis, not configuration auditing. To audit MFA properly, you need to extract configuration from the source of truth, Microsoft Graph.

The Authoritative Source: Microsoft Graph.

The Endpoint.

The Microsoft Graph endpoint /users/{id}/authentication/methods returns the full list of authentication methods registered for any given user:

GET https://graph.microsoft.com/v1.0/users/{id or UPN}/authentication/methods

Example output:

{
  "value": [
    {
      "@odata.type": "#microsoft.graph.passwordAuthenticationMethod"
    },
    {
      "@odata.type": "#microsoft.graph.microsoftAuthenticatorAuthenticationMethod",
      "displayName": "iPhone 17 Pro",
      "deviceTag": "SoftwareTokenActivated",
      "phoneAppVersion": "6.8.30"
    },
    {
      "@odata.type": "#microsoft.graph.fido2AuthenticationMethod",
      "model": "YubiKey 5 NFC"
    }
  ]
}

Each @odata.type identifies the authentication method type:

This data is far richer than anything available in the Entra GUI or tables and is the same source that Entra itself uses internally.

NOTE: The #microsoft.graph. prefix comes directly from the @odata.type field in the Microsoft Graph API response. It represents the fully qualified object type within the Graph schema (namespace microsoft.graph).

For readability, use the simplified form (for example, fido2AuthenticationMethod instead of #microsoft.graph.fido2AuthenticationMethod), but the full prefix is what you’ll see in the raw API data and Sentinel logs.

Solution Overview.

The goal is to automate collection of authentication method data using Azure Logic Apps and Microsoft Graph, then ingest the results into a custom Sentinel table (for example UserAuthMethods_CL).

This gives you a historical, queryable record of MFA configurations across your tenant, perfect for compliance reporting, audit evidence, or security investigations.

Examples.

Generate a readable MFA configuration summary per user:

userAuthMethods_CL
| extend UserPrincipalName = url_decode(extract(@"users\('(.+)'\)/authentication/", 1, _odata_context_s))
| mv-expand Auth = todynamic(value_s)
| extend MethodType = replace(@"#microsoft\.graph\.", "", tostring(Auth['@odata.type']))
| extend DeviceName = tostring(Auth.displayName)
| extend PhoneNumber = tostring(Auth.phoneNumber)
| extend DeviceTag = tostring(Auth.deviceTag)
| extend AppVersion = tostring(Auth.phoneAppVersion)
| extend Created = todatetime(Auth.createdDateTime)
| extend MethodDetail = case(
        MethodType == "microsoftAuthenticatorAuthenticationMethod", strcat("Authenticator: ", DeviceName, " (", DeviceTag, ", v", AppVersion, ")"),
        MethodType == "phoneAuthenticationMethod", strcat("Phone: ", PhoneNumber),
        MethodType == "windowsHelloForBusinessAuthenticationMethod", strcat("Windows Hello: ", DeviceName),
        MethodType == "fido2AuthenticationMethod", strcat("FIDO2 Key: ", DeviceName),
        MethodType == "passwordAuthenticationMethod", "Password only",
        strcat(MethodType, ": ", coalesce(DeviceName, PhoneNumber, DeviceTag))
    )
| summarize AuthSummary = strcat_array(make_set(MethodDetail), " | ") by UserPrincipalName
| project UserPrincipalName, AuthSummary
| order by UserPrincipalName asc
| where UserPrincipalName contains "me"

Summarize the number of users with each type of authentication method:

userAuthMethods_CL 
| extend
    username=url_decode(extract(@"users\('(.+)'\)/authentication/", 1, _odata_context_s))
| summarize arg_max(TimeGenerated, *) by username
| mv-expand todynamic(value_s)
| extend method=tostring(value_s["@odata.type"])
| summarize count() by method

Enrich Phone-Based MFA Records with Country Information.

let dialingCodes=externaldata(callingCode:string, countryName:string)
    [@'https://raw.githubusercontent.com/karani-gk/Country-Calling-Codes/refs/heads/main/Countries.csv'] with(format="csv");
userAuthMethods_CL 
| extend
    username=url_decode(extract(@"users\('(.+)'\)/authentication/", 1, _odata_context_s))
| summarize arg_max(TimeGenerated, *) by username
| mv-expand todynamic(value_s)
| extend method=tostring(value_s["@odata.type"])
| where method == "#microsoft.graph.phoneAuthenticationMethod"
| extend phoneNumber_ = tostring(value_s.phoneNumber)
| extend countryCode=substring(phoneNumber_, 0, 3)
| lookup (dialingCodes) on $left.countryCode==$right.callingCode

Scraping The Data.

The Microsoft Graph API exposes an endpoint that provides detailed information about each user’s registered authentication methods, exactly the data we need.

The Azure Logic App in this implementation automates that process by:

• Retrieving a complete list of users from the tenant.

• Querying the Microsoft Graph API for each user’s /authentication/methods endpoint.

• Forwarding the collected data into a custom Log Analytics table (userAuthMethods_CL) within Microsoft Sentinel for analysis and compliance reporting.

To allow the Logic App to query Microsoft Graph, it must be granted permission to access directory data. There are two ways to achieve this:

1. System-assigned managed identity:
   The Logic App can authenticate to Microsoft Graph using a managed identity, but this approach requires assigning high-privilege Entra ID roles (such as Directory Reader or Reports Reader).

2. App registration with OAuth:
   A more flexible and secure method is to create a dedicated Azure AD app registration and configure the Logic App to authenticate via OAuth 2.0.

The app registration only requires the following Microsoft Graph API permissions:

• UserAuthenticationMethod.Read.All

• User.Read.All

Designing The Collection Pipeline.

To continuously capture this data and make it available for analysis, you can automate the process using Azure Logic Apps.

A Logic App executes the following sequence every 24 hours:

1. List all users in the tenant using the /users Graph endpoint.

2. Query each user’s authentication methods using /users/{id}/authentication/methods.

3. Send the results to Sentinel through the Azure Log Analytics Data Collector connector.

This creates a custom table, userAuthMethods_CL, in your Sentinel workspace containing timestamped records of each user’s registered MFA methods.

Once the data is in Sentinel, you can query, summarise, or alert on MFA coverage with KQL.

Step 1/3: Enterprise App Registration.

To authenticate against Microsoft Graph securely without assigning broad system identities:

1. In the Entra ID admin center, navigate to App registrations.

2. Select New registration.

3. Name the application.

4. Choose Accounts in this organizational directory only (Single tenant)

5. Select Register.

6. Select API Permissions → Add a permission → Microsoft Graph → Application permissions.

7. Add the following permissions:

   1. UserAuthenticationMethod.Read.All

   2. User.Read.All

8. Choose Grant consent for your tenant.

9. Navigate to Certificates & Secrets → New client secret.

10. Choose an expiration date (The recommendation is 180 days/6 months) → Add.

11. Make a note of the client secret Value and Secret ID values, as you will need these later.

Step 2/3: Creating The Azure Logic App.

1. In the Azure portal, search Deploy a custom template.

2. Choose Build your own template in the editor.

3. Paste in the below deployment template → Save.

Deployment Template:

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "workflows_Get_Entra_AuthMethods_Logic_App_name": {
            "defaultValue": "Get-Entra-AuthMethods-Logic-App",
            "type": "String"
        },
        "connections_azureloganalyticsdatacollector_1_externalid": {
            "defaultValue": "/subscriptions/fb47e429-e603-41ff-86a1-36b85336ac4a/resourceGroups/soc-cdoherty-prod-rg/providers/Microsoft.Web/connections/azureloganalyticsdatacollector-1",
            "type": "String"
        }
    },
    "variables": {},
    "resources": [
        {
            "type": "Microsoft.Logic/workflows",
            "apiVersion": "2017-07-01",
            "name": "[parameters('workflows_Get_Entra_AuthMethods_Logic_App_name')]",
            "location": "uksouth",
            "identity": {
                "type": "SystemAssigned"
            },
            "properties": {
                "state": "Enabled",
                "definition": {
                    "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
                    "contentVersion": "1.0.0.0",
                    "parameters": {
                        "$connections": {
                            "defaultValue": {},
                            "type": "Object"
                        }
                    },
                    "triggers": {
                        "Recurrence": {
                            "recurrence": {
                                "interval": 24,
                                "frequency": "Hour",
                                "timeZone": "GMT Standard Time"
                            },
                            "evaluatedRecurrence": {
                                "interval": 24,
                                "frequency": "Hour",
                                "timeZone": "GMT Standard Time"
                            },
                            "type": "Recurrence"
                        }
                    },
                    "actions": {
                        "Get_all_users_from_Graph_API": {
                            "runAfter": {},
                            "type": "Http",
                            "inputs": {
                                "uri": "https://graph.microsoft.com/v1.0/users",
                                "method": "GET",
                                "authentication": {
                                    "type": "ActiveDirectoryOAuth",
                                    "authority": "https://login.microsoftonline.com",
                                    "tenant": "fd270158-ff15-46c6-b89c-8c989a167ade",
                                    "audience": "https://graph.microsoft.com",
                                    "clientId": "4169c87a-e141-4a23-8b3a-f3e7c54fd124",
                                    "secret": "tJe8Q~3Z4edikz8u3wAde1TYezB2OxIDQe_w-b.2"
                                }
                            }
                        },
                        "Parse_Users_JSON": {
                            "runAfter": {
                                "Get_all_users_from_Graph_API": [
                                    "Succeeded"
                                ]
                            },
                            "type": "ParseJson",
                            "inputs": {
                                "content": "@body('Get_all_users_from_Graph_API')",
                                "schema": {
                                    "type": "object",
                                    "properties": {
                                        "@@odata.context": {
                                            "type": "string"
                                        },
                                        "value": {
                                            "type": "array",
                                            "items": {
                                                "type": "object",
                                                "properties": {
                                                    "businessPhones": {
                                                        "type": "array"
                                                    },
                                                    "displayName": {
                                                        "type": "string"
                                                    },
                                                    "givenName": {},
                                                    "jobTitle": {},
                                                    "mail": {
                                                        "type": [
                                                            "string",
                                                            "null"
                                                        ]
                                                    },
                                                    "mobilePhone": {},
                                                    "officeLocation": {},
                                                    "preferredLanguage": {},
                                                    "surname": {},
                                                    "userPrincipalName": {
                                                        "type": "string"
                                                    },
                                                    "id": {
                                                        "type": "string"
                                                    }
                                                },
                                                "required": [
                                                    "userPrincipalName",
                                                    "id"
                                                ]
                                            }
                                        }
                                    }
                                }
                            }
                        },
                        "For_each_User": {
                            "foreach": "@outputs('Parse_Users_JSON')?['body']?['value']",
                            "actions": {
                                "If_user_is_not_external": {
                                    "actions": {
                                        "Get_User_Auth_Methods": {
                                            "type": "Http",
                                            "inputs": {
                                                "uri": "https://graph.microsoft.com/v1.0/users/@{item()?['userPrincipalName']}/authentication/methods",
                                                "method": "GET",
                                                "authentication": {
                                                    "type": "ActiveDirectoryOAuth",
                                                    "authority": "https://login.microsoftonline.com",
                                                    "tenant": "PutYourTenantIDHere",
                                                    "audience": "https://graph.microsoft.com",
                                                    "clientId": "PutYourClientIDHere",
                                                    "secret": "PutYourClientSecretHere"
                                                }
                                            }
                                        },
                                        "Send_Data_to_Sentinel": {
                                            "runAfter": {
                                                "Get_User_Auth_Methods": [
                                                    "Succeeded"
                                                ]
                                            },
                                            "type": "ApiConnection",
                                            "inputs": {
                                                "host": {
                                                    "connection": {
                                                        "name": "@parameters('$connections')['azureloganalyticsdatacollector-1']['connectionId']"
                                                    }
                                                },
                                                "method": "post",
                                                "body": "@{body('Get_User_Auth_Methods')}",
                                                "headers": {
                                                    "Log-Type": "userAuthMethods"
                                                },
                                                "path": "/api/logs"
                                            }
                                        }
                                    },
                                    "else": {
                                        "actions": {}
                                    },
                                    "expression": {
                                        "and": [
                                            {
                                                "not": {
                                                    "contains": [
                                                        "@item()?['userPrincipalName']",
                                                        "#EXT#"
                                                    ]
                                                }
                                            }
                                        ]
                                    },
                                    "type": "If"
                                }
                            },
                            "runAfter": {
                                "Parse_Users_JSON": [
                                    "Succeeded"
                                ]
                            },
                            "type": "Foreach"
                        }
                    },
                    "outputs": {}
                },
                "parameters": {
                    "$connections": {
                        "type": "Object",
                        "value": {
                            "azureloganalyticsdatacollector-1": {
                                "id": "/subscriptions/fb47e429-e603-41ff-86a1-36b85336ac4a/providers/Microsoft.Web/locations/uksouth/managedApis/azureloganalyticsdatacollector",
                                "connectionId": "[parameters('connections_azureloganalyticsdatacollector_1_externalid')]",
                                "connectionName": "azureloganalyticsdatacollector-1"
                            }
                        }
                    }
                }
            }
        }
    ]
}

Azure Logic App Design & Flow.

Below is the production Logic App definition used for this project.

{
  "definition": {
    "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
    "contentVersion": "1.0.0.0",
    "triggers": {
      "Recurrence": {
        "type": "Recurrence",
        "recurrence": {
          "interval": 24,
          "frequency": "Hour",
          "timeZone": "GMT Standard Time"
        }
      }
    },
    "actions": {
      "Get_all_users_from_Graph_API": {
        "type": "Http",
        "inputs": {
          "uri": "https://graph.microsoft.com/v1.0/users",
          "method": "GET",
          "authentication": {
            "type": "ActiveDirectoryOAuth",
            "authority": "https://login.microsoftonline.com",
            "tenant": "<tenant-id>",
            "audience": "https://graph.microsoft.com",
            "clientId": "<client-id>",
            "secret": "<client-secret>"
          }
        }
      },
      "Parse_Users_JSON": {
        "type": "ParseJson",
        "inputs": {
          "content": "@body('Get_all_users_from_Graph_API')",
          "schema": {
            "type": "object",
            "properties": {
              "value": {
                "type": "array",
                "items": {
                  "type": "object",
                  "properties": {
                    "userPrincipalName": { "type": "string" },
                    "id": { "type": "string" }
                  },
                  "required": [ "userPrincipalName", "id" ]
                }
              }
            }
          }
        },
        "runAfter": { "Get_all_users_from_Graph_API": [ "Succeeded" ] }
      },
      "For_each_User": {
        "type": "Foreach",
        "foreach": "@outputs('Parse_Users_JSON')?['body']?['value']",
        "actions": {
          "If_user_is_not_external": {
            "type": "If",
            "expression": {
              "not": {
                "contains": [
                  "@item()?['userPrincipalName']",
                  "#EXT#"
                ]
              }
            },
            "actions": {
              "Get_User_Auth_Methods": {
                "type": "Http",
                "inputs": {
                  "uri": "https://graph.microsoft.com/v1.0/users/@{item()?['userPrincipalName']}/authentication/methods",
                  "method": "GET",
                  "authentication": "@parameters('GraphOAuth')"
                }
              },
              "Send_Data_to_Sentinel": {
                "type": "ApiConnection",
                "inputs": {
                  "host": {
                    "connection": {
                      "name": "@parameters('$connections')['azureloganalyticsdatacollector-1']['connectionId']"
                    }
                  },
                  "method": "post",
                  "body": "@{body('Get_User_Auth_Methods')}",
                  "headers": { "Log-Type": "userAuthMethods" },
                  "path": "/api/logs"
                },
                "runAfter": { "Get_User_Auth_Methods": [ "Succeeded" ] }
              }
            }
          }
        },
        "runAfter": { "Parse_Users_JSON": [ "Succeeded" ] }
      }
    }
  }
}

Querying Data in Sentinel.

Once ingested, your data lives in userAuthMethods_CL and can be queried using KQL.

Inventory of FIDO2 models:

userAuthMethods_CL
| mv-expand todynamic(value_s)
| where value_s["@odata.type"] == "#microsoft.graph.fido2AuthenticationMethod"
| summarize count() by Model = tostring(value_s.model)

Summarise users by authentication method:

userAuthMethods_CL
| mv-expand todynamic(value_s)
| extend Method = tostring(value_s["@odata.type"])
| summarize Users = count() by Method
| order by Users desc

Benefits of the Logic App Approach.

This approach provides a complete and auditable dataset suitable for SOC analytics, MFA coverage validation, and compliance evidence for standards such as ISO 27001, Cyber Essentials Plus, and NCSC Cloud Security Principles.

Final Thoughts.

Native Entra reporting is management-level, useful for checking individual users but not for enterprise-scale auditing. By querying Graph through an automated Logic App and storing the data in Microsoft Sentinel, you create a long-term, analytical record of MFA registrations across your organisation.

This approach turns transient configuration data into an auditable evidence trail, exactly what compliance frameworks and SOC teams need to demonstrate effective MFA enforcement.

Managing inbound access to Azure resources through Network Security Groups (NSGs) is a standard best practice. NSGs define which IP addresses or ranges are permitted to communicate with your services, providing an essential layer of control for environments hosting management interfaces, firewalls, or Azure Virtual Desktop infrastructure.

The challenge arises when the authorised source WAN IP address changes frequently. This scenario is common for environments using DDNS, dynamic VPN gateways, partner networks, or externally managed endpoints.

Manually updating NSG rules to reflect a new source IP is both inefficient and prone to error.

In this article, I demonstrate how to automate NSG inbound security rule updates dynamically using a DNS hostname (for example, from Dynamic DNS), PowerShell, and Azure Automation. The result is a secure, credential-free automation that keeps your NSG rules continuously aligned with the current source IP address.

Understanding The Problem.

NSGs in Microsoft Azure operate at Layer 3 and Layer 4 of the network stack, enforcing allow or deny rules based on parameters such as source, destination, port, and protocol.

When the source address of a trusted endpoint changes, the corresponding rule must be updated to maintain connectivity.

For example, a VPN concentrator or external network may obtain a new public IP every few hours. Leaving the NSG source set to Any is insecure, yet manually updating the rule every time the IP changes is impractical.

As shown below, Azure NSG inbound security rules do not support Fully Qualified Domain Names (FQDNs) or hostnames. Only IP addresses or CIDR-based ranges can be used when defining the source or destination of a rule.

To handle frequently changing source addresses, Azure Automation can be used to periodically resolve a DNS record representing the authorised source and automatically update the NSG rule with the resolved IP.

Prerequisites.

Before implementing this solution, ensure the following requirements are met:

1. Azure Subscription: Sufficient permissions to create resources and assign roles.

2. Existing Network Security Group (NSG): Containing an inbound security rule that requires dynamic source IP management.

3. DNS Hostname: A resolvable DNS record (for example, a DDNS hostname) that maps to the current public IP of the authorised network. I use a service called No-IP for this.

We will create:

• An Azure Automation account.

• A system-assigned managed identity.

• A runbook, linked to a schedule.

Solution Overview.

The solution uses an Azure Automation Runbook to maintain NSG rules dynamically.

Your DNS hostname (for example, mynetwork.ddns.net) resolves to the current public IP of the trusted source. This could represent an office or home network that you access over VPN (for instance OpenVPN).

The Runbook executes a PowerShell script that:

• Resolves the hostname to its current IP address.

• Retrieves the NSG configuration.

• Compares the existing rule source to the resolved IP.

• Updates the rule only when a change is detected.

The Runbook authenticates to Azure using its Managed Identity, eliminating the need for credentials or secrets. This ensures that NSG rules remain accurate, secure, and automatically synchronised with DNS resolution.

Step 1/5: Creating The Azure Automation Account.

1. In the Azure Portal, navigate to Automation Accounts → Create.

2. On the Basics tab:

   1. Specify an Azure Subscription, and the resource group containing the NSG.

   2. Enter a name for the Automation Account.

   3. Choose the same region as your NSG.

3. On the Advanced tab:

   1. Keep the managed identity selection as System assigned.

4. On the Networking tab:

   1. Keep the connectivity configuration as Public access.

5. Select Review + Create → Create.

Step 2/5: Configuring Permissions.

1. Once the Automation Account has been created:

2. Navigate to your NSG.

   1. In the Azure Portal, select the search bar and search for Network security groups and select your NSG.

3. Select Access control (IAM) → Add → Add role assignment.

4. On the Role tab:

   1. Select Network Contributor on page 4 → Next.

5. On the Members tab:

   1. Choose Managed Identity → Select members → Automation Account → and select the name of the automation account that you created in step 1.

   2. Select Review + Assign to complete the assignment.

This grants the Automation Account permission to modify NSG rules using least-privilege access.

Step 3/5: Creating The PowerShell Runbook.

Below is the production-ready PowerShell script that performs the dynamic update.

It authenticates using a Managed Identity, resolves the DNS hostname, retrieves the NSG inbound security rule, and applies changes only when the source IP differs.

param(
    [string]$ResourceGroupName = "PutYourResourceGroupNameHere",
    [string]$NsgName = "PutYourNetworkSecurityGroupNameHere",
    [string]$RuleName = "PutYourRuleNameHere",
    [string]$DnsName = "PutYourDDNSorFQDNHere"
)

# Log start
Write-Output "Starting NSG update process for $DnsName"

# Authenticate with the system-assigned managed identity
Connect-AzAccount -Identity

# Resolve DDNS hostname to IP
try {
    $resolvedIP = (Resolve-DnsName -Name $DnsName -Type A).IPAddress
    Write-Output "Resolved IP: $resolvedIP"
} catch {
    Write-Error "Failed to resolve $DnsName"
    exit 1
}

# Retrieve the NSG
try {
    $nsg = Get-AzNetworkSecurityGroup -Name $NsgName -ResourceGroupName $ResourceGroupName
} catch {
    Write-Error "Failed to get NSG $NsgName from $ResourceGroupName"
    exit 1
}

# Retrieve the rule
$rule = $nsg.SecurityRules | Where-Object { $_.Name -eq $RuleName }

if (-not $rule) {
    Write-Error "Rule '$RuleName' not found in NSG '$NsgName'"
    exit 1
}

# Get current source
$currentSource = if ($rule.SourceAddressPrefix -is [System.Array]) {
    $rule.SourceAddressPrefix -join ","
} else {
    $rule.SourceAddressPrefix
}

# Compare and update if required
if ($currentSource -ne $resolvedIP) {
    Write-Output "Updating rule '$RuleName' SourceAddressPrefix from '$currentSource' to '$resolvedIP'"

    try {
        # Properly modify the NSG rule
        $nsg | Set-AzNetworkSecurityRuleConfig `
            -Name $RuleName `
            -Protocol $rule.Protocol `
            -Direction $rule.Direction `
            -Priority $rule.Priority `
            -SourceAddressPrefix $resolvedIP `
            -SourcePortRange $rule.SourcePortRange `
            -DestinationAddressPrefix $rule.DestinationAddressPrefix `
            -DestinationPortRange $rule.DestinationPortRange `
            -Access $rule.Access

        # Commit the update to Azure
        Set-AzNetworkSecurityGroup -NetworkSecurityGroup $nsg
        Write-Output "Update complete. Rule '$RuleName' now allows only $resolvedIP."
    } catch {
        Write-Error "Failed to update rule '$RuleName': $_"
        exit 1
    }
} else {
    Write-Output "No change detected. Current IP already matches."
}

Ensure you replace the placeholder variables ($ResourceGroupName, $NsgName, $RuleName, $DnsName) at the top of the script.

Step 4/5: Publishing The Automation Runbook.

1. In the Azure portal, navigate to Automation Accounts → Process Automation → Runbooks.

2. Select Create a Runbook.

1. Provide a name, and choose Powershell as the Runbook type.

2. Choose 7.2 (or later) as the Runtime version.

3. Select Review + Create → Create.

4. Then, open the runbook, and select Edit → Edit in portal.

5. Paste the above PowerShell code, and change the variables as highlighted previously.

6. Choose Save, and then select Test in pane.

If your inbound security rule currently has its source set to Any, a successful test should replace it with the resolved IP address.

Example result:

Example output:

Completed
Starting NSG update process for [REDACTED].ddns.net

Environments                                                                                           Context
------------                                                                                           -------
{[AzureCloud, AzureCloud], [AzureUSGovernment, AzureUSGovernment], [AzureChinaCloud, AzureChinaCloud]} Microsoft.Azure.…

Resolved IP: [REDACTED]
Resolved IP: [REDACTED]
No change detected. Current IP already matches.

Once verified, publish the Runbook.

Step 5/5: Scheduling The Runbook.

Finally, schedule the Runbook to ensure it runs automatically. In this example, I will schedule the runbook to run every hour.

1. Ensure that your runbook is in a published state:

2. Select the runbook → Link to schedule → Schedule (Link a schedule to your runbook).

3. Choose Add a schedule.

4. Name the schedule.

5. Set the start date.

6. Select Recurring.

7. Set the recur to 1 Hour.

8. Set the expiration (if needed).

9. Select Create.

Verification.

After the first scheduled runbook execution, check the NSG in the Azure Portal under Inbound security rules. You should see that the rule’s Source field reflects the current IP resolved from your DNS hostname.

You will also see the scheduled run in the Overview page, under recent jobs.

Example Scenario.

To illustrate this automation in practice, consider the following real-world use case.

I have deployed a Sophos Firewall (SFOS) virtual appliance in Microsoft Azure. This appliance provides both a Management, User Portal and a VPN Portal, typically accessible on TCP ports 443, 4443 and 4444 by default. While these portals can be essential for administrative and remote user access, exposing them directly to the public internet is not recommended.

From a security and compliance standpoint, unrestricted WAN exposure conflicts with:

• Cyber Essentials requirements for minimising externally exposed management interfaces.

• NCSC Cloud Security Principles, which advise strict control over administrative interfaces.

• NIST SP 800-41 and 800-125 guidelines, which recommend that VPN and firewall management endpoints are not accessible from untrusted networks.

In this scenario, I want to securely manage and access the Sophos Firewall without exposing the User or VPN portals to the WAN.

However, my office network connection uses a dynamic public IP address provided by my ISP. This means the IP changes periodically, breaking any static NSG rule that restricts inbound access.

To address this, I use a Dynamic DNS (DDNS) hostname, for example vpn.ddns.net, which always points to my home network’s current IP address. I can connect to my network at any time using OpenVPN, but since Azure Network Security Groups do not support FQDNs or DDNS resolution natively, the NSG cannot reference vpn.ddns.net directly.

Instead, the Azure Automation Runbook dynamically resolves the DDNS hostname and updates the inbound NSG rule for the Sophos firewall. This ensures that:

• Only my current, trusted office IP address is permitted inbound access to the VPN and User Portals.

• The firewall remains effectively non-public, in compliance with Cyber Essentials, NCSC, and NIST best practices.

• The automation continuously maintains secure access without manual intervention each time my IP changes.

This approach combines least-privilege network access with automation and identity-based security, removing both administrative overhead and risk exposure.

Conclusion.

Automating NSG rule updates with Azure Automation and PowerShell provides an elegant and secure solution to managing dynamic inbound access.

By resolving a DNS hostname and applying the corresponding IP address to your Network Security Group rule, you eliminate the need for manual intervention while maintaining the principle of least privilege.

This method is lightweight, cost-effective, and entirely managed within the Azure platform. It scales easily to multiple environments, supports credential-free authentication via Managed Identity, and can be extended with monitoring, notifications, or audit logging for enterprise-grade governance.

Whether you are managing Azure Virtual Desktop session hosts, VPN gateways, or administrative endpoints, this approach ensures continuous and secure access control without compromising operational efficiency.

Understanding who can do what in Azure is one of the most common pain points for businesses adopting or scaling their cloud infrastructure. Assigning permissions might appear straightforward—until a user with “Contributor” access cannot assign a role, deploy a service, or view cost data.

These types of roadblocks are especially common when developers, DevOps engineers, or IT support teams are expected to build or manage infrastructure but lack the necessary access.

This guide was written to remove the guesswork. It covers the fundamentals of Azure Role-Based Access Control (RBAC), explains the purpose and limitations of common built-in roles, and maps those roles to specific operational tasks.

Whether you're managing SQL resources, deploying Function Apps, configuring managed identities, or setting policies, this article will help you understand the exact permissions needed—and the best way to assign them securely.

By the end of this guide, you should be able to:

• Confidently determine which Azure role is required for a given task

• Avoid the pitfalls of over- or under-provisioning access

• Support technical users with the correct access model from the outset

This article is ideal for IT service providers, internal support teams, and cloud engineers who want to align autonomy with governance in Azure.

Azure RBAC Explained.

Azure Role-Based Access Control (RBAC) is Microsoft’s native system for managing access to Azure resources. It allows organisations to grant users only the permissions they need to perform specific tasks, and nothing more—supporting the principle of least privilege.

Each role assignment in Azure consists of three parts:

• Security Principal: The user, group, or service principal being granted access.

• Role Definition: A predefined or custom set of permissions (e.g. Reader, Contributor, Owner).

• Scope: The level at which the permissions apply—this can be a subscription, resource group, or specific resource.

Understanding this model is essential to managing Azure securely and effectively. A user might have the right role but at the wrong scope, leading to frustrating permission errors.

Key Built-in Roles (and What They Actually Do).

Microsoft Azure includes a long list of built-in roles, but for most practical cases, the following are the most relevant:

Note: Assigning a role at a higher scope (e.g. subscription) gives access to everything underneath it (e.g. all resource groups and resources).

Common Microsoft Azure Tasks & The Roles Required.

The following sections explain what roles are needed for common Azure administration tasks, including those frequently encountered in service desk escalations and infrastructure deployments.

1.1 Creating and managing resource groups.

A common mistake is assuming Contributor alone allows IAM changes. It does not.

1.2 Creating and managing Azure subscriptions.

Azure subscription management takes place largely outside the Azure portal, often via the Microsoft 365 admin centre or Azure EA/partner portals.

You cannot create new Azure subscriptions directly from the Azure portal without billing permissions in Microsoft 365.

1.3 Budget and Cost Monitoring

The Contributor role alone does not allow access to cost tools unless explicitly granted.

1.4 Managing App Registrations and Service Principals

Azure Active Directory (Entra ID) governs identity-related actions. Roles assigned in the Azure portal alone are insufficient for app registration control.

1.5 Deploying Secure Workloads with Managed Identities

Managed Identities allow services to authenticate securely without passwords or connection strings.

1.6 Azure SQL Servers and Databases

Azure SQL requires both RBAC and SQL-specific permissions. Some access must be configured within SQL itself.

1.7 Key Vaults and Secrets

Key Vault is highly secured. Access must be explicitly granted, regardless of Contributor rights.

1.8 Azure Function Apps and Automation Workloads

1.9 Creating and Applying Azure Policy

Policy allows organisations to enforce compliance controls across resources.

A Contributor cannot create or assign policies unless explicitly granted the Policy Contributor role.

Summary: Suggested Role Set For A Cloud Engineer.

For someone building and managing Azure infrastructure autonomously (e.g. a DevOps or Lead Software Engineer), the following roles should be considered:

If autonomy must be balanced with oversight, use Privileged Identity Management (PIM) to grant time-limited access to elevated roles.

Custom Roles & Security Groups In Azure.

In some scenarios, the built-in roles provided by Microsoft do not precisely match the requirements of your organisation. For example, you may want to grant a user the ability to manage storage accounts but not virtual networks, or allow access to Cost Management tools without exposing billing settings.

1.1 Custom Roles.

Custom roles allow you to define a permission set tailored to your organisation’s needs. They are created using Azure Resource Manager and consist of a list of allowed actions, denied actions, and the scope to which they apply.

Custom roles require planning and testing but can significantly reduce over-permissioning.
Learn more: Create or update Azure custom roles

1.2 Security Groups for Role Assignments.

Rather than assigning roles directly to individuals, it is best practice to assign RBAC roles to Microsoft Entra security groups. This offers several advantages:

• Scalability: Assign a role once to the group, and it applies to all members.

• Audibility: Easily see who inherits access via group membership.

• Lifecycle management: Use Entra dynamic groups or HR-connected provisioning to manage group population.

Security groups can be used both in Azure RBAC and Entra roles (e.g. Application Administrator), making them a key part of scalable access control.

Tip: Assigning roles to groups makes permissions easier to audit and rotate when staff change roles.

Final Thoughts.

Azure permissions are powerful, but when misconfigured, either by selecting the wrong role or applying it at the wrong scope, they can introduce serious barriers to progress.

Poorly assigned access can delay deployments, create security gaps, undermine governance, and prevent critical infrastructure from being managed effectively.

Avoid defaulting to "Contributor" or "Owner" for all users. Instead, use targeted combinations of roles like Contributor + User Access Administrator, Application Administrator, and Key Vault Administrator to provide operational access without compromising governance.

As teams scale, consider formalising a permissions baseline per role (e.g. Developer, DevOps, Analyst), and use Azure PIM to support just-in-time access for high-risk actions.

DNS record manipulation is a subtle yet powerful technique often used by threat actors to intercept communication, reroute authentication flows, or disrupt services. Despite its impact, DNS change monitoring is often overlooked in security monitoring strategies.

A recent report on Risky Business focused on attacks by a group, seemingly exhibiting similar TTPs to Scattered Spider, where MX records for a target's domain were altered to redirect inbound emails. This easily allows for the compromise of multiple other platforms and accounts, as well as inhibiting recovery due to the inability of the victim to receive their own emails.

This article demonstrates how to implement DNS record change detection in Microsoft Sentinel using Azure Logic Apps and DNS-over-HTTPS (DoH). The approach enables visibility into unauthorised or accidental changes to DNS records, such as MX, A, or TXT entries, which could have significant security implications.

The solution requires no third-party agents or premium tools—only Azure-native components and a free DoH service. A sample Logic App template and KQL detection rule are provided to help you deploy the solution in minutes.

Why Monitor DNS Records?

Attackers can exploit DNS by:

• Changing MX records to hijack emails.

• Altering SPF or TXT records to spoof emails.

• Modifying A records to redirect services.

Unless you're actively monitoring DNS, these changes can go unnoticed until it's too late. Microsoft Azure Sentinel doesn't do this natively, so we’re building a custom detection method.

Some monitoring platforms (such as PRTG) allow for monitoring of specific DNS records and alerting on changes. However for any organizations that don't have this functionality available, a dedicated alternative based in Azure is useful.

This monitoring solution is based on an Azure Logic App which sends details of DNS records into Sentinel where an analytics rule can monitor for changes.

If possible I'd also suggest taking audit logs from the DNS hosting platform to look for these kinds of changes, but some platforms don't provide such functionality.

Prerequisites.

• Microsoft Sentinel connected to a Log Analytics workspace.

• Permissions to create Logic Apps and deploy templates.

• A public DoH resolver like Cloudflare.

• At least one domain name you want to monitor.

Deploy The Azure Logic App To Collect DNS Records.

This Logic App periodically queries DNS records for your domain via DNS-over-HTTPS (DoH) using Cloudflare's free service, then forwards the data to Microsoft Sentinel via the Log Analytics Data Collector API.

Create the Logic App.

1. In the Azure portal, search for Logic Apps and create a new Standard Logic App.

2. Assign it to the same resource group as your Sentinel workspace for ease of management.

3. Choose the Region closest to your resources, preferably matching Sentinel workspace location for latency optimisation.

Configure Variables.

1. Add an Initialise Variable action named recordTypes (type: Array).

   1. Set the value to ["A", "MX", "TXT"] or include any additional record types you wish to track.

2. Optionally, create another variable named domains with your domain list, for example: ["domain.co.uk"].

Add a Recurrence Trigger.

1. Configure the Logic App to run on a defined schedule, for example, every 5 minutes, depending on how frequently you wish to monitor changes.

Loop Through Record Types.

Within the Logic App, create a loop to iterate through each DNS record type stored in the recordTypes array.

For every type, the Logic App will query Cloudflare’s DNS-over-HTTPS endpoint, interpret the results, and forward the findings to Microsoft Sentinel.

The loop begins by making an HTTP GET request to Cloudflare’s API using the following structure:

https://cloudflare-dns.com/dns-query?name=domain.co.uk&type=@{items('For_each_recordType')}

The request header must specify that the response should be in DNS JSON format:

accept: application/dns-json

Once the request completes, the response can be parsed. In most Logic App environments, the HTTP connector automatically returns JSON data, but if your configuration encodes it in base64, you can decode it using a Compose action with this expression:

@json(base64ToString(body('DoH_Request')?['$content']))

The output from this stage contains an array named Answer, representing the DNS responses. The next loop iterates through this array so that each record—whether it’s an A, MX, or TXT entry—is processed individually.

For each record, the Logic App then sends structured data to Microsoft Sentinel through the Azure Log Analytics Data Collector connector. The payload includes key details such as the domain, record type, name, TTL, and record data, along with a timestamp for correlation. A typical payload looks like this:

{
  "TimeGenerated": "@{utcNow()}",
  "QueriedDomain": "domain.co.uk",
  "RecordName": "@{item()?['name']}",
  "RecordType": "@{items('For_each_recordType')}",
  "TTL": "@{item()?['TTL']}",
  "RecordData": "@{item()?['data']}"
}

Make sure the request headers include:

Log-Type: dnsmonitor
Content-Type: application/json

Once ingested, Sentinel automatically creates a custom log table named dnsmonitor_CL, where each row represents a single DNS record snapshot. These entries can then be queried in KQL to detect any changes or anomalies over time.

Logic App JSON Definition.

Below is the complete Logic App JSON Definition:

{
  "definition": {
    "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
    "contentVersion": "1.0.0.0",
    "triggers": {
      "5_Min_Timer": {
        "type": "Recurrence",
        "recurrence": {
          "interval": 5,
          "frequency": "Minute"
        }
      }
    },
    "actions": {
      "Set_recordtypes_variable": {
        "type": "InitializeVariable",
        "inputs": {
          "variables": [
            {
              "name": "recordTypes",
              "type": "array",
              "value": [
                "A",
                "MX",
                "TXT"
              ]
            }
          ]
        },
        "runAfter": {}
      },
      "For_each_recordType": {
        "type": "Foreach",
        "foreach": "@variables('recordTypes')",
        "actions": {
          "DoH_Request": {
            "type": "Http",
            "inputs": {
              "uri": "https://cloudflare-dns.com/dns-query?name=yourdomain.co.uk&type=@{items('For_each_recordType')}",
              "method": "GET",
              "headers": {
                "accept": "application/dns-json"
              }
            }
          },
          "Decode_Response": {
            "type": "Compose",
            "inputs": "@json(base64ToString(body('DoH_Request')?['$content']))",
            "runAfter": {
              "DoH_Request": [
                "Succeeded"
              ]
            }
          },
          "For_each_Answer": {
            "type": "Foreach",
            "foreach": "@outputs('Decode_Response')?['Answer']",
            "actions": {
              "Send_to_Sentinel": {
                "type": "ApiConnection",
                "inputs": {
                  "host": {
                    "connection": {
                      "name": "@parameters('$connections')['azureloganalyticsdatacollector-1']['connectionId']"
                    }
                  },
                  "method": "post",
                  "path": "/api/logs",
                  "headers": {
                    "Log-Type": "dnsmonitor"
                  },
                  "body": {
                    "QueriedDomain": "domain.co.uk",
                    "RecordName": "@{item()?['name']}",
                    "RecordType": "@{items('For_each_recordType')}",
                    "TTL": "@{item()?['TTL']}",
                    "RecordData": "@{item()?['data']}"
                  }
                }
              }
            },
            "runAfter": {
              "Decode_Response": [
                "Succeeded"
              ]
            }
          }
        },
        "runAfter": {
          "Set_recordtypes_variable": [
            "Succeeded"
          ]
        }
      }
    },
    "outputs": {},
    "parameters": {
      "$connections": {
        "type": "Object",
        "defaultValue": {}
      }
    }
  },
  "parameters": {
    "$connections": {
      "type": "Object",
      "value": {
        "azureloganalyticsdatacollector-1": {
          "id": "/subscriptions/fb47e429-e603-41ff-86a1-36b85336ac4a/providers/Microsoft.Web/locations/uksouth/managedApis/azureloganalyticsdatacollector",
          "connectionId": "/subscriptions/fb47e429-e603-41ff-86a1-36b85336ac4a/resourceGroups/yourresourcegroupnamehere/providers/Microsoft.Web/connections/azureloganalyticsdatacollector-1",
          "connectionName": "azureloganalyticsdatacollector-1"
        }
      }
    }
  }
}

Remember to change your domain name in the uri input string on line 39, and your resource group name on 110.

Microsoft Sentinel (SIEM) Alerting.

Once the information is ingested within Microsoft Sentinel, a straightforward analytics rule can monitor for additions and deletions. This is configured below as a NRT (near real time) rule. If you run this less frequently, you may need to modify the time thresholds.

let records=dnsmonitor_CL
    | mv-expand parse_json(Answer_s)
    | extend
        domain=tostring(parse_json(Question_s)[0]['name']),
        answer=tostring(Answer_s['data'])
    | summarize firstSeen=min(TimeGenerated), lastSeen=max(TimeGenerated) by domain, answer;
let lastRun=toscalar(records
    | summarize max(lastSeen));
let newRecords=records
    | where firstSeen > ago(8m)
    | extend action="New";
let deletedRecords=records
    | where lastSeen < ago(8m)
    | extend action="Removed";
union newRecords, deletedRecords

Introduction.

Cisco Umbrella is a cloud-delivered security platform that provides DNS-layer protection, secure web gateway (SWG), cloud-delivered firewall, and cloud access security broker (CASB) capabilities. It enforces security policies and blocks threats at the DNS and IP layers before connections are established, making it a powerful first line of defence in a layered security model.

Cisco Umbrella logs can include DNS requests, proxy traffic, IP-layer events, and firewall decisions depending on your licensing and configuration. These logs offer valuable insight into user activity, threat prevention actions, and internet-bound traffic patterns.

It delivers DNS protection across endpoints, ensuring that users and devices are secure no matter the environment, which makes protecting users that work from home a breeze.

Integrating Cisco Umbrella with Microsoft Entra ID allows for centralised identity management, secure single sign-on (SSO), and improved visibility across your organisation's secure web gateway traffic. By federating identity, user authentication and access control policies can be managed consistently, aligning with enterprise identity governance standards.

This article section outlines the process to configure identity federation between Cisco Umbrella and Microsoft Entra ID, enabling user-based policy enforcement and reporting.

Step 1: Creating The Cisco Umbrella Enterprise Application in Entra ID.

1. Navigate to the Microsoft Entra ID portal:

   • https://entra.microsoft.com/#view/Microsoft_AAD_IAM/AppGalleryBladeV2

2. Select the Cisco User Management for Secure Access application and create it.

   1. 

Step 2: Configuring the Entra ID Application Using A Cisco Umbrella Static API.

Once added, proceed with configuring SSO and SAML-based sign-on. Cisco provides the necessary metadata XML or input fields:

1. • Sign in to the Cisco Umbrella dashboard.

     • Navigate to Admin > API Keys > Static Keys.

     • Select Azure Active Directory Provisioning and create an API token.

       • Copy the URL and token and save them somewhere securely. The URL should look something like: https://api.umbrella.com/identity/v2/scim.

Step 3: Provisioning Identities from Microsoft Entra ID.

Set up the app in the Microsoft Entra ID portal with your Cisco Umbrella token and Azure Active Directory Provisioning URL (collected from the previous step):

1. Navigate to the enterprise application (created in Step 1).

2. Add your token to the Secret Token field.

3. Add the Azure Active Directory Provisioning URL to the Tenant URL field.

4. Click Test Connection to confirm that you can use your Umbrella SCIM token to connect the Umbrella API with Microsoft Entra ID.

5. Complete the steps to provision users from Microsoft Entra ID to Umbrella. Review the user attributes that are synchronized from Microsoft Entra ID to the Cisco User Management Connector app in Attribute Mappings. The attributes selected as Matching properties are used to match the user accounts in the Cisco User Management Connector app for update operations. If you choose to change the matching target attribute, ensure that the Cisco User Management Connector app supports filtering users based on that attribute.

6. Click Save.

Section 2: Microsoft Azure Sentinel (SIEM) Integration For Log Analysis.

Introduction.

Cisco Umbrella offers valuable security telemetry including DNS-layer threat detection, proxy activity, and cloud access visibility. Integrating these logs into Microsoft Sentinel enables enriched correlation, threat hunting, and incident response across your broader security ecosystem.

This section covers the process of integrating Cisco Umbrella logs into Sentinel using Log Analytics workspace connectors and parsing them for effective SIEM use.

Use this Microsoft article for reference for ingesting DNS logs into Microsoft Azure Sentinel: https://learn.microsoft.com/en-us/azure/sentinel/data-connectors-reference#cisco-umbrella-preview

Overview.

Cisco Umbrella supports log export to AWS S3. Microsoft Sentinel ingests these logs using a pre-built Azure Function template found in the Content Hub. This allows continuous ingestion and analysis of DNS and security events in Sentinel for threat detection, investigation, and response.

Step 1: Integrating Cisco Umbrella Logs into Microsoft Sentinel Using the Azure Template Method.

To begin ingesting logs from Cisco Umbrella into Microsoft Sentinel, the first step is to enable Umbrella's log export functionality. Cisco Umbrella supports exporting logs to an Amazon S3 bucket. When you enable this feature from the Umbrella dashboard, a new managed S3 bucket will be provisioned on your behalf by Cisco.

During this process, you will be provided with three important values: the S3 bucket path (or "data path"), an AWS access key, and a corresponding secret key. These credentials are only visible once during the setup, so it is essential to copy and store them securely at the time.

These details can be found within the Cisco Umbrella dashboard:

• Navigate to Admin > Log Management > Amazon S3.

Step 2: Installing The Microsoft Sentinel Content Solution.

Once Umbrella log export has been configured and your keys are stored, the next stage takes place in Microsoft Sentinel.

1. Navigate to Microsoft Azure Sentinel > Content Management > Content Hub.

2. Search for Cisco Umbrella and select the featured solution from the list.

3. Select Install to begin deploying the solution.

Step 3: Deploying the Azure ARM Template.

Once installed:

1. Navigate to Configuration > Data connectors > Cisco Umbrella (Using Azure Functions) and open the connector page.

2. Choose the Azure Resource Manager (ARM) Template deployment method. This is the recommended approach for most environments and requires no manual code configuration.

   • The ARM template method will launch a deployment blade in Azure with a form that needs to be completed using the information from Umbrella and your Sentinel workspace.

The steps for deploying the template are as follows:

1. Provide a Function App Name. This must be unique across your tenant (e.g., sentinel-umbrella-fnapp).

2. Select a Region that matches your Sentinel Log Analytics workspace.

3. Enter your Workspace Name and the full Workspace Resource ID, which can be copied from Azure or referenced from 1Password.

4. In the AWS section of the form, input the S3 bucket path (as given in the Cisco Umbrella console), specify the region (e.g. eu-west-2), and paste in the AWS access key ID and secret key that were provided by Umbrella during activation.

5. Click Review + Create, then Create to deploy the function app.

6. Verify that the connector status shows Connected.

If you encounter any issues when deploying the template, verify that you have sufficient permissions within the resource group.

Step 4: Verify Log Ingestion.

Logs are uploaded in ten-minute intervals from the Umbrella log queue to the S3 bucket. Within the first two hours after a completed configuration, you should receive your first log upload to your S3 bucket.

To check to see if everything is working, the Last Sync time in the Umbrella dashboard should update and logs should begin to appear in your S3 bucket.

Example:

"2024-09-11 18:46:00","Active Directory User ([adusername@example.net](mailto:adusername@example.net))","Active Directory User ([adusername@example.net](mailto:adusername@example.net)),WIN11-SNG01-Example","10.10.1.100","24.123.132.133","Allowed","1 (A)","NOERROR","domain-visited.com.","Software/Technology,Business Services,Allow List,Infrastructure and Content Delivery Networks,SaaS and B2B,Application","AD Users","AD Users,Anyconnect Roaming Client","","506165","","8234970"

The example entry above is 480 bytes. To estimate the size of your S3 Logs, see Estimate the Size of Your Logs.

Order of Fields in the DNS log:

<timestamp><most granular identity><identities><internal ip><external ip><action><query type><response code><domain><categories><most granular identity type><identity types><blocked categories><rule id><destination countries><organization id>

• Timestamp—When this request was made in UTC. This is different than the Umbrella dashboard, which converts the time to your specified time zone.

• Most Granular Identity—The first identity matched with this request in order of granularity.

• Identities—All identities associated with this request.

• Internal IP—The internal IP address that made the request.

• External IP—The external IP address that made the request.

• Action—Whether the request was allowed or blocked.

• Query Type—The type of DNS request that was made. For more information, see Common DNS Request Types.

• Response Code—The DNS return code for this request. For more information, see Common DNS return codes for any DNS service (and Umbrella).

• Domain—The domain that was requested.

• Categories—The security or content categories that the destination matches. For category definitions, see Understanding Security Categories and Understanding Content Categories.

• Most Granular Identity Type—The first identity type matched with this request in order of granularity. Available in version 3 and above.

• Identity Types—The type of identity that made the request. For example, Roaming Computer, Network, and so on. Available in version 3 and above.

• Blocked Categories—The categories that resulted in the destination being blocked. Available in version 4 and above.

• Rule ID—The ID of the access rule when the DNS request is matched by a policy.

• Destination Countries—The two-character country identifier of the domain that was requested.

• Organization ID—The Umbrella organization ID. For more information, see Find Your Organization ID.

For more information, read this article: https://docs.umbrella.com/deployment-umbrella/docs/dns-log-formats

Step 5: Verify Log Ingestion - KQL.

Once log ingestion has been established, the Cisco Umbrella connector will populate multiple custom log tables within your Log Analytics workspace. These typically include:

• Cisco_Umbrella_dns_CL

• Cisco_Umbrella_proxy_CL

• Cisco_Umbrella_ip_CL

• Cisco_Umbrella_cloudfirewall_CL

To confirm that logs are being ingested and structured as expected, open the Logs blade within your Sentinel workspace and run the following basic queries:

DNS Log Verification

Cisco_Umbrella_dns_CL
| take 10

This query will return the latest 10 DNS logs ingested from Umbrella. If the connector is functioning correctly, you should see structured records including fields such as timestamp_t, InternalIP_s, Domain_s, Action_s, and Categories_s.

To filter DNS logs by action (e.g. blocked):

Cisco_Umbrella_dns_CL
| where Action_s == "Blocked"
| project timestamp_t, Domain_s, InternalIP_s, Identities_s, Categories_s
| sort by timestamp_t desc

This allows you to identify recently blocked DNS queries, which can be used for detection rules or investigation.

Search for DNS Queries to a Specific Domain

Cisco_Umbrella_dns_CL
| where Domain_s endswith "example.com"
| project timestamp_t, Domain_s, InternalIP_s, Action_s, Identities_s

This will return logs showing requests to any subdomain under example.com.

Filter by Identity Type (e.g. Roaming Client)

Cisco_Umbrella_dns_CL
| where IdentityTypes_s has "Roaming"
| summarize Count = count() by bin(timestamp_t, 1h), IdentityTypes_s
| sort by timestamp_t desc

This provides a high-level view of DNS activity coming specifically from roaming clients over time.

Proxy Log Verification.

If Umbrella Secure Web Gateway (SWG) is in use and proxy logs are being exported, confirm ingestion with:

Cisco_Umbrella_proxy_CL
| take 10

Best Practices for Queries.

• Always use time filters (e.g. where timestamp_t > ago(1d)) to limit the result set and optimise performance.

• Combine fields such as InternalIP_s, Domain_s, and Categories_s to build actionable detections.

• Leverage Kusto functions to alias and reuse logic consistently in scheduled rules and hunting queries.

For optimal performance, consider creating custom functions or scheduled analytics rules that alert on high-risk DNS activity, such as queries to known malicious domains or sudden spikes in traffic to newly registered TLDs.

→ Next Steps:

Once ingestion and validation are complete, you can begin to build custom detection rules, dashboards, and investigations using the data. You may also wish to enable or create custom analytic rules for SOC incident and alerting.

Sentinel's native integration with Microsoft Defender XDR also enables enriched correlation between Umbrella telemetry and endpoint, identity, and email signals.

For further schema details and field references, consult the official Cisco documentation.

In a world where organisations rely on complex digital systems, the ability to respond quickly to incidents can be the difference between a minor disruption and a major breach. Two essential metrics that help measure and improve response efficiency are MTTA (Mean Time to Acknowledge) and MTTR (Mean Time to Respond/Resolve).

Although frequently referenced, these terms are often misunderstood or used interchangeably. This article will explain what they mean, why they matter, and how they’re used in real-world IT and security operations.

What Is MTTA?

Mean Time to Acknowledge (MTTA) refers to the average time it takes from when an alert or incident is first raised to when a human acknowledges it. Acknowledgement typically means someone (usually an analyst, engineer, or responder) has seen the alert and formally begun the investigation process.

For example, if an intrusion detection system flags suspicious behaviour at 14:00, and a SOC analyst opens the alert at 14:03, the time to acknowledge or MTTA is 3 minutes.

Why MTTA Matters:

• A low MTTA means alerts are being seen quickly, enabling faster triage.

• A high MTTA could indicate alert fatigue, understaffed teams, or ineffective alerting (e.g., too many false positives).

• In Cyber Security, every minute counts. A slow acknowledgement can provide attackers more time to escalate privileges or exfiltrate data.

What Is MTTR?

Mean Time to Respond (or Resolve) is the average time it takes from incident detection to full remediation or closure. This metric often varies based on what "response" is defined to mean, whether it's neutralising a threat, restoring a system, or fully patching a vulnerability.

For example, if a ransomware infection is detected at 09:00 and fully contained and cleaned up by 11:30, the time to resolve, or MTTR, is 2.5 hours.

Why MTTR Matters:

• MTTR reflects operational readiness and efficiency in incident response.

• A lower MTTR often correlates with mature playbooks, skilled analysts, and effective automation.

• In regulated industries, MTTR can impact compliance, SLAs, and reporting obligations.

MTTA vs. MTTR: Key Differences:

They serve different purposes: MTTA measures alert visibility and team responsiveness, while MTTR measures overall remediation efficiency.

How to Improve MTTA and MTTR.

1. Automate low-risk triage.

• Use SOAR platforms to auto-close benign alerts or escalate high-severity ones with rich context.

2. Tune your detection rules.

• Eliminate noisy or low-value alerts that delay acknowledgement of serious incidents.

3. Improve incident documentation.

• Clear runbooks and standard operating procedures (SOPs) reduce decision-making time.

4. Train staff effectively.

• Regular tabletop exercises and red-teaming help analysts build muscle memory.

5. Implement alert routing.

• Ensure alerts are directed to the right team or specialist, reducing hand-off delays.

Real-World Example: Sentinel & Defender XDR.

In Microsoft Sentinel integrated with Microsoft Defender XDR, MTTA could be the time between a Sentinel Analytics Rule triggering and a SOC analyst opening the incident.

MTTR, on the other hand, could span the entire response lifecycle, from investigation and containment in Defender to remediation actions taken via Intune or third-party tooling.

Final Thoughts.

Measuring MTTA and MTTR isn’t just about metrics. While they’re often seen as indicators of SOC or IT performance, they’re more usefully treated as guiding tools for identifying bottlenecks and opportunities for improvement.

With rising attack sophistication and shrinking response windows, reducing both MTTA and MTTR should be a continuous priority for any modern security team.

Whether you're defending the cloud, responding to incidents in a SOC, or tightening access controls as an identity engineer, staying ahead of the curve means continuously sharpening your skills.

Microsoft’s official Ninja Training Series is one of the most underrated resources in the security community — offering deep, scenario-based learning for free. While many practitioners know about the well-circulated Sentinel or Defender paths, several advanced and recently released Ninja trainings remain largely undiscovered.

This article curates all known Microsoft Ninja Training programmes — including those often missed, newly updated, or hidden in Tech Community threads — so you can level up across the entire Microsoft security stack.

Let’s turn you into a true Microsoft Ninja.

Microsoft Security Academy.

The Microsoft Security Academy is a learning platform designed to equip individuals with the knowledge and skills necessary for cybersecurity roles. It offers a wide range of resources and training modules focused on Microsoft's security solutions, including Microsoft Sentinel, Microsoft Defender, Microsoft Entra, and Microsoft Purview. These resources are created and delivered by experts within Microsoft's security-aligned teams.

https://microsoft.github.io/PartnerResources/skilling/microsoft-security-academy

Security teams within Managed Security Service Providers (MSSPs) or multi-brand organisations often require visibility into several isolated Microsoft Sentinel instances. Without centralisation, analysts must switch between portals or accounts—inefficient, error-prone, and lacking holistic visibility.

Azure Lighthouse solves this by delegating access to customer tenants using Azure Resource Manager (ARM), allowing a single security operations team to manage incidents, hunting, workbooks, and automation across all tenants.

The Need for Multi-Tenant Management.

Security operations teams often face challenges when managing multiple isolated Sentinel deployments. Without a centralised approach, analysts must log into separate portals or switch accounts, reducing efficiency and increasing the risk of misconfigurations or oversight.

Azure Lighthouse addresses this by enabling secure, delegated access to customer tenants. With proper configuration, it allows central SOC teams to investigate incidents, run queries, and manage Sentinel workspaces without direct tenant access or identity switching.

Key Benefits of Azure Lighthouse Integration.

Using Azure Lighthouse with Microsoft Sentinel provides several operational advantages. It allows for centralised security monitoring, role-based access control using Azure RBAC, streamlined analyst workflows, and consistent deployment of processes and automation. Analysts can interact with delegated Sentinel environments as if they were part of their own tenant, reducing friction and increasing responsiveness to threats.

Use Case: Multi-Tenant SOC Operations.

With Lighthouse in place, a central SOC team can monitor multiple environments simultaneously. Analysts can perform triage on incidents, investigate threats using Kusto Query Language (KQL), and trigger Logic App playbooks to respond to alerts.

Although each Sentinel workspace operates independently in terms of data and analytics rules, centralised access simplifies day-to-day security operations and governance.

Limitations and Considerations.

There are some limitations to be aware of. Data ingestion and retention remain within the customer tenant and are billed accordingly. Analytics rules and hunting queries must be deployed individually per tenant; there is no global rule propagation across workspaces.

Workbooks, playbooks, and custom connectors are also isolated and must be manually deployed or automated via DevOps processes. Additionally, role scoping should always adhere to the principle of least privilege.

Conclusion.

Deploying Microsoft Sentinel in multi-tenant environments can introduce significant operational complexity if not centralised properly. Azure Lighthouse provides a scalable, secure, and compliant method for centralising access to Microsoft Sentinel workspaces across tenant boundaries.

For MSSPs and enterprise security teams, this integration enables streamlined investigations, consistent automation, and enhanced visibility without compromising on control or security.

If you require a downloadable version of the ARM templates or diagrams to support this article, please get in touch or refer to Microsoft’s Azure Lighthouse documentation.

While making a small update to an analytics rule in Microsoft Sentinel, I hit an unexpected roadblock. I tried saving the rule, and Sentinel threw this error:

Failed to save analytics rule '[REDACTED]'. Conflict: Newer instance of rule '[REDACTED]' exists for workspace '[REDACTED]' (ETag does not match). Data was not saved.

This happens when the rule has been modified elsewhere (e.g., by another user), and Sentinel uses an ETag to detect those changes. It's designed to stop you from accidentally overwriting a newer version, but in this case, it just blocked me from saving a minor update.

What I Did Instead.

Rather than digging into ARM templates or scripting around it, I took a simple approach:

1. Duplicated the rule manually.

2. Adjusted the rule name slightly (just capitalised the words).

3. Applied my change.

4. Disabled the original rule.

5. Tested the new one.

6. Deleted the old rule once everything checked out.

Quick, Clean, Done.

This is probably not the “correct” or a recommended solution. But for a low-risk edit in a controlled environment, this workaround saved me a lot of time and avoided unnecessary overhead.

If Sentinel ever throws an ETag conflict your way, and the change is minor, starting fresh might be faster than fighting it.

In modern Security Operations Centres (SOCs), the ability to rapidly query large volumes of telemetry data is critical to effective incident response and threat hunting. Microsoft Sentinel, underpinned by Azure Log Analytics, leverages the Kusto Query Language (KQL) — a powerful, intuitive syntax built for scalability and speed. This article outlines a selection of high-value KQL queries that every SOC analyst should be familiar with to detect suspicious behaviour, correlate incidents, and reduce mean time to resolution (MTTR).

1: Sign-In Activity.

1.1: Identify recent sign-ins for a specific user with ASN, IP, and device details over a 10 day period.

let targetUser = "FirstName.LastName";
let timeWindow = 10d;
SigninLogs
| where TimeGenerated >= ago(timeWindow)
| where tolower(UserPrincipalName) has tolower(targetUser)
| extend Device = DeviceDetail, Location = LocationDetails, CAPolicies = parse_json(ConditionalAccessPolicies)
| mv-expand CAPolicy = CAPolicies
| extend
    CA_DisplayName = tostring(CAPolicy.displayName),
    CA_Result = tostring(CAPolicy.result),
    CA_GrantControls = iif(array_length(CAPolicy.enforcedGrantControls) > 0, strcat_array(CAPolicy.enforcedGrantControls, ", "), "")
| summarize
    CA_Policy_Summary = make_set(strcat(CA_DisplayName, iif(CA_GrantControls != "", strcat(" (", CA_GrantControls, ")"), ""), " → ", CA_Result))
    by
    TimeGenerated,
    ResultType,
    IPAddress,
    ASN = tostring(AutonomousSystemNumber),
    DeviceID = tostring(Device.deviceId),
    DeviceName = tostring(Device.displayName),
    OS = tostring(Device.operatingSystem),
    Browser = tostring(Device.browser),
    TrustType = tostring(Device.trustType),
    App = AppDisplayName,
    ClientApp = ClientAppUsed,
    ConditionalAccess = tostring(ConditionalAccessStatus),
    MFA = tostring(MfaDetail),
    City = tostring(Location.city),
    State = tostring(Location.state),
    Country = tostring(Location.countryOrRegion),
    Latitude = tostring(Location.geoCoordinates.latitude),
    Longitude = tostring(Location.geoCoordinates.longitude),
    UserAgent
| project
    SigninTime = TimeGenerated,
    ResultType,
    IPAddress,
    ASN,
    DeviceID,
    DeviceName,
    OS,
    Browser,
    TrustType,
    App,
    ClientApp,
    ConditionalAccess,
    CA_Policy_Summary,
    MFA,
    City,
    State,
    Country,
    Latitude,
    Longitude,
    UserAgent
| sort by SigninTime desc
// NOTE:
// This query returns all interactive sign-ins for the specified user over the past 10 days.
// It includes IP address, ASN, device details, trust type, application used, Conditional Access results, and MFA status.
// Applied Conditional Access policies are listed with any enforced grant controls.
// This is useful for reviewing user sign-in behaviour and evaluating CA policy effectiveness.
// Limitations:
// It only includes interactive sign-ins. Device trust type or location may be incomplete for personal devices.
// Post-sign-in activity is not shown — use OfficeActivity or CloudAppEvents for that.

1.2: Summarise user behaviour and Conditional Access (CA) trends over a 30 day period:

let BaseData = 
SigninLogs
| where TimeGenerated >= ago(30d)
| where UserDisplayName contains "FirstName LastName"
| extend
    LocationDetails = tostring(Location),
    App = tostring(AppDisplayName),
    Resource = tostring(ResourceDisplayName),
    ClientApp = tostring(ClientAppUsed),
    AuthRequirement = tostring(AuthenticationRequirement),
    AuthRequirementPolicies = tostring(AuthenticationRequirementPolicies),
    CAStatus = tostring(ConditionalAccessStatus),
    CAPoliciesRaw = tostring(ConditionalAccessPolicies),
    MFA = tostring(MfaDetail),
    DeviceID = tostring(DeviceDetail.DeviceId),
    DeviceName = tostring(DeviceDetail.DisplayName),
    OperatingSystem = tostring(DeviceDetail.OperatingSystem),
    Browser = tostring(DeviceDetail.Browser),
    IsCompliant = tostring(DeviceDetail.IsCompliant),
    IsManaged = tostring(DeviceDetail.IsManaged),
    IsAzureADJoined = tostring(DeviceDetail.IsAzureADJoined),
    IsHybridAzureADJoined = tostring(DeviceDetail.IsHybridAzureADJoined),
    UserAgent = tostring(UserAgent),
    ASN = tostring(AutonomousSystemNumber);
let CA_Policy_Summary = 
BaseData
| where isnotempty(CAPoliciesRaw)
| extend CAPolicyObjects = parse_json(CAPoliciesRaw)
| mv-apply policy = CAPolicyObjects on (
    where policy.result in~ ("success", "failure", "reportOnlyNotApplied")
    | extend CAPolicySummary = strcat(
        tostring(policy.displayName), " → ", tostring(policy.result),
        iif(array_length(policy.enforcedGrantControls) > 0,
            strcat(" (", strcat_array(policy.enforcedGrantControls, ", "), ")"),
            "")
    )
)
| summarize SampleCAPolicies = make_set(CAPolicySummary) by IPAddress, ASN, UserPrincipalName;
BaseData
| summarize
    SuccessfulLogins = countif(ResultType == 0),
    FailedLogins = countif(ResultType != 0),
    CA_Applied_Success = countif(CAStatus == "success"),
    CA_Applied_Failure = countif(CAStatus == "failure"),
    CA_NotApplied = countif(CAStatus == "notApplied"),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated),
    SampleDevice = any(DeviceName),
    SampleOS = any(OperatingSystem),
    SampleBrowser = any(Browser),
    SampleADJoin = any(IsAzureADJoined),
    SampleHybridJoin = any(IsHybridAzureADJoined),
    SampleCompliant = any(IsCompliant),
    SampleManaged = any(IsManaged),
    SampleApp = any(App),
    SampleResource = any(Resource),
    SampleClientApp = any(ClientApp),
    SampleAuthRequirement = any(AuthRequirement),
    SampleAuthPolicies = any(AuthRequirementPolicies),
    SampleCAStatus = any(CAStatus),
    SampleMFA = any(MFA),
    SampleUserAgent = any(UserAgent),
    Location = any(LocationDetails),
    DeviceDetailObject = any(DeviceDetail)
  by IPAddress, ASN, UserPrincipalName
| join kind=leftouter CA_Policy_Summary on IPAddress, ASN, UserPrincipalName
| extend SampleCAPolicies = strcat_array(SampleCAPolicies, " | ")
| sort by LastSeen desc
| project
    IPAddress,
    ASN,
    UserPrincipalName,
    SuccessfulLogins,
    FailedLogins,
    CA_Applied_Success,
    CA_Applied_Failure,
    CA_NotApplied,
    FirstSeen,
    LastSeen,
    SampleDevice,
    SampleOS,
    SampleBrowser,
    SampleADJoin,
    SampleHybridJoin,
    SampleCompliant,
    SampleManaged,
    SampleApp,
    SampleResource,
    SampleClientApp,
    SampleAuthRequirement,
    SampleAuthPolicies,
    SampleCAStatus,
    SampleCAPolicies,
    SampleMFA,
    SampleUserAgent,
    Location,
    DeviceDetailObject
// NOTE: This query summarises all interactive sign-ins, even when no Conditional Access policies were evaluated.
// It separately extracts CA policy details where present and joins them back in, preserving full coverage of all sign-in IPs.
// Ideal for user behavioural summaries, not intended for incident forensics or conditional access policy effectiveness analysis without validation.

1.3: Summarise non-interactive (AADNonInteractiveUserSignInLogs) sign-ins for a specific user with ASN, IP, device details and Conditional Access (CA) over a 30-day period:

AADNonInteractiveUserSignInLogs
| where TimeGenerated >= ago(30d)
| where UserPrincipalName contains "FirstName.LastName"
| extend DeviceDetailParsed = parse_json(DeviceDetail)
| extend
    DeviceID = tostring(DeviceDetailParsed["deviceId"]),
    DeviceName = tostring(DeviceDetailParsed["displayName"]),
    OperatingSystem = tostring(DeviceDetailParsed["operatingSystem"]),
    Browser = tostring(DeviceDetailParsed["browser"]),
    TrustType = tostring(DeviceDetailParsed["trustType"]),
    IsCompliant = tostring(DeviceDetailParsed["isCompliant"]),
    IsManaged = tostring(DeviceDetailParsed["isManaged"]),
    App = tostring(AppDisplayName),
    Resource = tostring(ResourceDisplayName),
    ClientApp = tostring(ClientAppUsed),
    AuthRequirement = tostring(AuthenticationRequirement),
    AuthRequirementPolicies = tostring(AuthenticationRequirementPolicies),
    CAStatus = tostring(ConditionalAccessStatus),
    CAPolicies = tostring(ConditionalAccessPolicies),
    MFA = tostring(MfaDetail),
    UserAgent = tostring(UserAgent),
    ASN = tostring(AutonomousSystemNumber)
| summarize
    SuccessfulLogins = countif(ResultType == 0),
    FailedLogins = countif(ResultType != 0),
    CA_Applied_Success = countif(CAStatus == "success"),
    CA_Applied_Failure = countif(CAStatus == "failure"),
    CA_NotApplied = countif(CAStatus == "notApplied"),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated),
    SampleDevice = any(DeviceName),
    SampleOS = any(OperatingSystem),
    SampleBrowser = any(Browser),
    SampleTrust = any(TrustType),
    SampleCompliant = any(IsCompliant),
    SampleManaged = any(IsManaged),
    SampleApp = any(App),
    SampleResource = any(Resource),
    SampleClientApp = any(ClientApp),
    SampleAuthRequirement = any(AuthRequirement),
    SampleAuthPolicies = any(AuthRequirementPolicies),
    SampleCAStatus = any(CAStatus),
    SampleCAPolicies = any(CAPolicies),
    SampleMFA = any(MFA),
    SampleUserAgent = any(UserAgent),
    DeviceDetailObject = any(DeviceDetailParsed),
    ASN = any(ASN)
  by IPAddress, UserPrincipalName
| sort by LastSeen desc
| project
    IPAddress,
    ASN,
    UserPrincipalName,
    SuccessfulLogins,
    FailedLogins,
    CA_Applied_Success,
    CA_Applied_Failure,
    CA_NotApplied,
    FirstSeen,
    LastSeen,
    SampleDevice,
    SampleOS,
    SampleBrowser,
    SampleTrust,
    SampleCompliant,
    SampleManaged,
    SampleApp,
    SampleResource,
    SampleClientApp,
    SampleAuthRequirement,
    SampleAuthPolicies,
    SampleCAStatus,
    SampleCAPolicies,
    SampleMFA,
    SampleUserAgent,
    DeviceDetailObject
// NOTE: This query summarises non-interactive sign-in activity (such as token refreshes and service-to-service authentications) per user and IP over the past 30 days.
// It is intended for visibility and correlation purposes only. Do not use this query to audit interactive user behaviour or sign-in intent.
// Always validate with interactive sign-in logs (SigninLogs), raw activity logs, or session records where authentication context is critical.

2: Microsoft SharePoint, OneDrive, & Cloud Activity.

2.1: Summarise deleted SharePoint/OneDrive file activity by file type:

let FileActivity = 
    OfficeActivity
    | where UserId contains "FirstName.LastName"
    | where Operation has_any("FileVersionsAllDeleted", "FileDeleted", "FileRecycled", "FolderRecycled")
    | extend FileType = extract(@"\.(\w+)$", 1, SourceFileName), SiteUrl = Site_Url, SourceRelativeUrl = SourceRelativeUrl, Operation = Operation, RecordType = RecordType, OfficeWorkload = OfficeWorkload, EventSource = EventSource, ItemType = ItemType, SensitivityLabelId = SensitivityLabelId, UserId_ = UserId, ClientIP = ClientIP, UserAgent = UserAgent, IsManagedDevice = IsManagedDevice, Type = Type;
union
(
    FileActivity
    | summarize Count = count() 
    | extend FileType = "Total", FileNames = "", SiteUrl = "", SourceRelativeUrl = "", Operation = "", RecordType = "", OfficeWorkload = "", EventSource = "", ItemType = "", SensitivityLabelId = "", UserId_ = "", ClientIP = "", UserAgent = "", IsManagedDevice = "", Type = ""
),
(
    FileActivity
    | summarize Count = count(), FileNamesList = make_list(SourceFileName, 100000), SiteUrlList = make_list(SiteUrl, 100000), SourceRelativeUrlList = make_list(SourceRelativeUrl, 100000), OperationList = make_list(Operation, 100000), RecordTypeList = make_list(RecordType, 100000), OfficeWorkloadList = make_list(OfficeWorkload, 100000), EventSourceList = make_list(EventSource, 100000), ItemTypeList = make_list(ItemType, 100000), SensitivityLabelIdList = make_list(SensitivityLabelId, 100000), UserId_List = make_list(UserId_, 100000), ClientIPList = make_list(ClientIP, 100000), UserAgentList = make_list(UserAgent, 100000), IsManagedDeviceList = make_list(IsManagedDevice, 100000), TypeList = make_list(Type, 100000) by FileType
    | extend FileNames = strcat_array(FileNamesList, "\n"), SiteUrl = strcat_array(SiteUrlList, "\n"), SourceRelativeUrl = strcat_array(SourceRelativeUrlList, "\n"), Operation = strcat_array(OperationList, "\n"), RecordType = strcat_array(RecordTypeList, "\n"), OfficeWorkload = strcat_array(OfficeWorkloadList, "\n"), EventSource = strcat_array(EventSourceList, "\n"), ItemType = strcat_array(ItemTypeList, "\n"), SensitivityLabelId = strcat_array(SensitivityLabelIdList, "\n"), UserId_ = strcat_array(UserId_List, "\n"), ClientIP = strcat_array(ClientIPList, "\n"), UserAgent = strcat_array(UserAgentList, "\n"), IsManagedDevice = strcat_array(IsManagedDeviceList, "\n"), Type = strcat_array(TypeList, "\n")
    | project FileType, Count, FileNames, SiteUrl, SourceRelativeUrl, Operation, RecordType, OfficeWorkload, EventSource, ItemType, SensitivityLabelId, UserId_, ClientIP, UserAgent, IsManagedDevice, Type
)
| extend SortOrder = iif(FileType == "Total", 1000000, Count)
| order by SortOrder desc
| project-away SortOrder
| project Count, FileType, FileNames, SiteUrl, SourceRelativeUrl, Operation, RecordType, OfficeWorkload, EventSource, ItemType, SensitivityLabelId, UserId_, ClientIP, UserAgent, IsManagedDevice, Type

2.2: Summarise downloaded SharePoint/OneDrive file activity by file type:

let FileActivity = 
    OfficeActivity
    | where UserId contains "FirstName.LastName"
    | where Operation has_any("FileDownloaded")
    | extend FileType = extract(@"\.(\w+)$", 1, SourceFileName), SiteUrl = Site_Url, SourceRelativeUrl = SourceRelativeUrl, Operation = Operation, RecordType = RecordType, OfficeWorkload = OfficeWorkload, EventSource = EventSource, ItemType = ItemType, SensitivityLabelId = SensitivityLabelId, UserId_ = UserId, ClientIP = ClientIP, UserAgent = UserAgent, IsManagedDevice = IsManagedDevice, Type = Type;
union
(
    FileActivity
    | summarize Count = count() 
    | extend FileType = "Total", FileNames = "", SiteUrl = "", SourceRelativeUrl = "", Operation = "", RecordType = "", OfficeWorkload = "", EventSource = "", ItemType = "", SensitivityLabelId = "", UserId_ = "", ClientIP = "", UserAgent = "", IsManagedDevice = "", Type = ""
),
(
    FileActivity
    | summarize Count = count(), FileNamesList = make_list(SourceFileName, 100000), SiteUrlList = make_list(SiteUrl, 100000), SourceRelativeUrlList = make_list(SourceRelativeUrl, 100000), OperationList = make_list(Operation, 100000), RecordTypeList = make_list(RecordType, 100000), OfficeWorkloadList = make_list(OfficeWorkload, 100000), EventSourceList = make_list(EventSource, 100000), ItemTypeList = make_list(ItemType, 100000), SensitivityLabelIdList = make_list(SensitivityLabelId, 100000), UserId_List = make_list(UserId_, 100000), ClientIPList = make_list(ClientIP, 100000), UserAgentList = make_list(UserAgent, 100000), IsManagedDeviceList = make_list(IsManagedDevice, 100000), TypeList = make_list(Type, 100000) by FileType
    | extend FileNames = strcat_array(FileNamesList, "\n"), SiteUrl = strcat_array(SiteUrlList, "\n"), SourceRelativeUrl = strcat_array(SourceRelativeUrlList, "\n"), Operation = strcat_array(OperationList, "\n"), RecordType = strcat_array(RecordTypeList, "\n"), OfficeWorkload = strcat_array(OfficeWorkloadList, "\n"), EventSource = strcat_array(EventSourceList, "\n"), ItemType = strcat_array(ItemTypeList, "\n"), SensitivityLabelId = strcat_array(SensitivityLabelIdList, "\n"), UserId_ = strcat_array(UserId_List, "\n"), ClientIP = strcat_array(ClientIPList, "\n"), UserAgent = strcat_array(UserAgentList, "\n"), IsManagedDevice = strcat_array(IsManagedDeviceList, "\n"), Type = strcat_array(TypeList, "\n")
    | project FileType, Count, FileNames, SiteUrl, SourceRelativeUrl, Operation, RecordType, OfficeWorkload, EventSource, ItemType, SensitivityLabelId, UserId_, ClientIP, UserAgent, IsManagedDevice, Type
)
| extend SortOrder = iif(FileType == "Total", 1000000, Count)
| order by SortOrder desc
| project-away SortOrder
| project Count, FileType, FileNames, SiteUrl, SourceRelativeUrl, Operation, RecordType, OfficeWorkload, EventSource, ItemType, SensitivityLabelId, UserId_, ClientIP, UserAgent, IsManagedDevice, Type

3: Email Events.

3.1: Summarise email activity by sender domain (including URLs, attachments, recipients, and post-delivery actions.

let targetDomain = "domain.com";
let FilteredEmails = EmailEvents
| where SenderFromDomain == targetDomain;
let AttachmentInfo = EmailAttachmentInfo
| project NetworkMessageId, FileName, SHA256
| summarize AttachmentBlock = strcat_array(make_list(strcat("- ", FileName, " (SHA256: ", SHA256, ")")), "\n") by NetworkMessageId;
let UrlInfo = EmailUrlInfo
| project NetworkMessageId, Url
| extend SanitisedUrl = replace_string(replace_regex(Url, "\\.(com|net|org|co\\.uk|io|gov|uk|biz|edu|info|me|to|ai|careers)", "[.\\1]"), "://", "[://]");
let ClickInfo = UrlClickEvents
| project NetworkMessageId, Url
| summarize ClickedUrls = make_set(Url) by NetworkMessageId;
let UrlWithClicks = UrlInfo
| join kind=leftouter (ClickInfo) on NetworkMessageId
| extend ClickStatus = iff(set_has_element(ClickedUrls, Url), "Yes", "No")
| summarize UrlList = make_list(strcat(SanitisedUrl, "|", ClickStatus)) by NetworkMessageId;
let UrlBlockFormatted = UrlWithClicks
| mv-apply UrlList on (
    serialize
    | extend UrlIndex = row_number()
    | extend URLInfo = split(UrlList, "|")
    | extend UrlLine = strcat("URL ", tostring(UrlIndex), ": ", URLInfo[0], " | Clicked: ", URLInfo[1])
)
| summarize UrlCount = count(), UrlBlock = strcat_array(make_list(UrlLine), "\n") by NetworkMessageId;
let RecipientsByEmail = FilteredEmails
| project NetworkMessageId, RecipientEmailAddress
| summarize Recipients = make_list(RecipientEmailAddress) by NetworkMessageId
| extend RecipientCount = array_length(Recipients)
| extend RecipientBlock = iff(RecipientCount == 0, "Recipients: None", strcat("Recipients (", tostring(RecipientCount), "):\n", strcat_array(Recipients, "\n")));
let PostDeliveryActions = FilteredEmails
| project NetworkMessageId
| join kind=leftouter (
    EmailPostDeliveryEvents
    | project NetworkMessageId, Action, ActionTrigger, ActionType, ThreatTypes
) on NetworkMessageId
| summarize PostDeliveryAction = strcat_array(make_list(strcat("Action: ", Action, " | Trigger: ", ActionTrigger, " | Type: ", ActionType, " | Threats: ", tostring(ThreatTypes))), "\n") by NetworkMessageId
| extend PostDeliverySummary = iff(isempty(PostDeliveryAction), "🚨 No post-delivery actions found 🚨", strcat("🚨 Post-delivery action(s) 🚨\n", PostDeliveryAction));
FilteredEmails
| project Subject, NetworkMessageId, InternetMessageId, Timestamp, SenderFromAddress, DeliveryAction, EmailLanguage, RecipientEmailAddress
| join kind=leftouter (AttachmentInfo) on NetworkMessageId
| join kind=leftouter (UrlBlockFormatted) on NetworkMessageId
| join kind=leftouter (RecipientsByEmail) on NetworkMessageId
| join kind=leftouter (PostDeliveryActions) on NetworkMessageId
| extend AttachmentText = iff(isnull(AttachmentBlock), "Attachments: None", strcat("Attachments:\n", AttachmentBlock))
| extend UrlText = iff(isnull(UrlBlock), "URLs: None", strcat("URLs (", tostring(UrlCount), "):\n", UrlBlock))
| extend RecipientText = iff(isnull(RecipientBlock), "Recipients: None", RecipientBlock)
| extend PostDeliveryText = iff(isnull(PostDeliverySummary), "🚨 No post-delivery actions found 🚨", PostDeliverySummary)
| extend Template = "==== EMAIL ====\n{postdelivery}\nTime: {time}\nSender: {sender}\nDelivery: {delivery}\nLanguage: {lang}\n{recipients}\n{urls}\n{attachments}\nInternet Msg ID: {imid}\nNetwork Msg ID: {nmid}"
| extend Step1 = replace_string(Template, "{time}", format_datetime(Timestamp, "yyyy-MM-dd HH:mm:ss"))
| extend Step2 = replace_string(Step1, "{sender}", SenderFromAddress)
| extend Step3 = replace_string(Step2, "{delivery}", DeliveryAction)
| extend Step4 = replace_string(Step3, "{lang}", EmailLanguage)
| extend Step5 = replace_string(Step4, "{recipients}", RecipientText)
| extend Step6 = replace_string(Step5, "{urls}", UrlText)
| extend Step7 = replace_string(Step6, "{attachments}", AttachmentText)
| extend Step8 = replace_string(Step7, "{postdelivery}", PostDeliveryText)
| extend Step9 = replace_string(Step8, "{imid}", tostring(InternetMessageId))
| extend EmailDetail = replace_string(Step9, "{nmid}", tostring(NetworkMessageId))
| summarize Emails = make_list(EmailDetail) by Subject;

4: Network Traffic Logs.

4.1: Detect suspicious or anomalous activity in IIS logs.

W3CIISLog
|where * =="1.1.1.1"

//further details

W3CIISLog
|where sIP =="1.1.1.1"
|summarize attempts=count() by bin(TimeGenerated,1h)
|render timechart

5. Security Events & AD.

5.1: Retrieve details of user(s) added to security group(s).

SecurityEvent
| where EventID == 4728
| project-rename AD_Group_Name = TargetAccount
| project TimeGenerated, Account, AccountType, AD_Group_Name, Channel, Task, EventSourceName, EventID, Activity, MemberName, MemberSid, SubjectAccount, SubjectDomainName, SubjectUserName, SubjectUserSid, TargetUserName

5.2: Identify recent service installations over a 10-day period.

SecurityEvent
| where EventID == 4697
| where TimeGenerated > ago(10d)
| project TimeGenerated, Computer, Account, ServiceName, ServiceFileName, ServiceType, ServiceStartType, ServiceAccount, SubjectUserName, SubjectDomainName
| sort by TimeGenerated desc

5.3: Investigate NTDS.dit access.

DeviceFileEvents
| where FileName =~ "ntds.dit"
| where InitiatingProcessFileName !in~ ("ntdsutil.exe", "esentutl.exe", "mimikatz.exe", "powershell.exe", "cmd.exe")
| summarize count() by InitiatingProcessFileName, InitiatingProcessCommandLine
// Identifies processes creating/accessing `ntds.dit` and excludes known credential dumping tools.
// Useful for confirming benign process (e.g., `dockerd.exe`) is responsible.
// Does not show timeline or file path details — use with path-based query.

Many Security Operation Centres (SOCs) rely on rapid, structured, and context-rich alerting mechanisms.

This blog outlines how to build an interactive, dynamic workflow to send Microsoft Sentinel incidents to Microsoft Teams using an Azure Logic App and Adaptive Cards.

This solution enables SOC teams to:

• Receive incident alerts in real time within Microsoft Teams.

• View key incident metadata in a clean UI.

• Take action such as changing severity or closing incidents.

• Operate entirely within Microsoft Teams, improving speed and reducing context-switching.

Prerequisites:

To complete this interaction, you’ll need the following:

• A Microsoft Sentinel instance (active and connected to a Log Analytic Workspace).

• Azure Logic App (Standard or Consumption).

• Microsoft Teams with an appropriate channel.

• Adaptive Card Designer (adaptivecards.io)

• Contributor permissions on the relevant resource group.

Example.

Step 1: Designing the Adaptive Card.

The Adaptive Card is the UI element that appears in Teams. Begin by building your Adaptive Card using the web-based Designer tool. Set the host app to "Microsoft Teams - Dark" to preview how it will render in Teams.

Card content:

1. Header Text: Large title (e.g. “New Microsoft Sentinel Incident Created!”)

2. Microsoft Sentinel Logo: Insert into a left-hand column using image URL
   https://connectoricons-prod.azureedge.net/releases/v1.0.1391/1.0.1391.2130/azuresentinel/icon.png

3. Clickable Incident Link: Markdown [Click here to view the Incident](incidentURL)

4. FactSet Section: Display the following dynamically retrieved incident properties:

   1. Incident Title

   2. Incident ID

   3. Creation Time (UTC)

   4. Severity (with conditional colours)

   5. Alert Providers (joined with ; )

   6. MITRE ATT&CK Tactics (joined with ; )

   7. Description

Action section:

Beneath the incident details:

1. Dropdown: Close Incident
   ID: incidentStatus
   Choices:

   Close incident - False Positive → FalsePositive – IncorrectAlertLogic

   • Close incident - True Positive → TruePositive – SuspiciousActivity

   • Close incident - Benign Positive → BenignPositive – SuspiciousButExpected

   • Don’t close the incident → no (default)

2. Dropdown: Change Severity
   ID: incidentSeverity

   Choices:

   • High

   • Medium

   • Low

   • Informational

   • Don’t change → same (default)

3. Submit Button
   Title: “Submit response!”

Copy the card JSON from the “Card Payload Editor” once built.

Step 2: Create the Azure Logic App.

1. Navigate to Microsoft Sentinel > Automation > Create > Playbook with incident trigger.

2. Configure:

   • Name: Send-Teams-Adaptive-Card-on-incident-creation

   • Resource Group: Your Sentinel resource group

   • Identity: Use a Managed Identity

3. Proceed to the Logic App Designer.

Step 3: Define Logic App Actions.

3.1: Compose the Adaptive Card:

1. Add a Compose action.

2. Paste your full Adaptive Card JSON (designed earlier).

3. Replace static placeholders with dynamic content from the Sentinel trigger.

Examples:

"value": "@{triggerBody()?['object']?['properties']?['title']}"

For arrays like Alert Providers:

"value": "@{join(triggerBody()?['object']?['properties']?['additionalData']?['alertProductNames'], '; ')}"

3.2: Post to Teams:

• Add an action: Microsoft Teams > Post adaptive card and wait for a response.

• Configure:

  • Post as: Flow bot

  • Post in: Teams channel

  • Message: Outputs from Compose

  • Update message: "Thanks for your response!"

Step 4: Process the Response.

4.1: Update Severity:

• Add Condition: if incidentSeverity is not equal to same

• Under True:

  • Add Update Incident (Sentinel)

  • Pass new severity from the card response using:

      body('Post_Adaptive_Card_and_wait_for_a_response')?['data']?['incidentSeverity']
    

4.2: Close the Incident:

• Add another Condition: if incidentStatus is not equal to no

• Under True:

  • Add Update Incident with status Closed

  • Add classification reason based on card input

Enhancements and Best Practices.

• Use attention, warning, and good colours to visually reflect incident severity

• Embed Sentinel and company logos in the card for professional branding

• Add follow-up cards or messages to Teams confirming actions taken

• Consider including user feedback or quick triage options (e.g. "Is this activity expected?")

Conclusion.

This integration brings security events directly into the operational workflow, reducing response time and enabling immediate action within Microsoft Teams. By automating incident delivery and embedding response options into the conversation flow, this method enhances visibility and efficiency in SOC environments.

→ Next Steps:

• Add enrichment (e.g. GeoIP, Identity Risk Levels).

• Extend with logic for multi-stage approvals.

• Publish your Adaptive Card JSON to internal GitHub for standardisation.

• Use role-based access to scope which alerts trigger playbooks.

Let incidents come to the team — not the other way around.