Azure Active Directory security operations for devices
Devices aren't commonly targeted in identity-based attacks, but can be used to satisfy and trick security controls, or to impersonate users. Devices can have one of four relationships with Azure AD:
Registered and joined devices are issued a Primary Refresh Token (PRT), which can be used as a primary authentication artifact, and in some cases as a multifactor authentication artifact. Attackers may try to register their own devices, use PRTs on legitimate devices to access business data, steal PRT-based tokens from legitimate user devices, or find misconfigurations in device-based controls in Azure Active Directory. With Hybrid Azure AD joined devices, the join process is initiated and controlled by administrators, reducing the available attack methods.
For more information on device integration methods, see Choose your integration methods in the article Plan your Azure AD device deployment.
To reduce the risk of bad actors attacking your infrastructure through devices, monitor
Device registration and Azure AD join
Non-compliant devices accessing applications
BitLocker key retrieval
Device administrator roles
Sign-ins to virtual machines
Where to look
The log files you use for investigation and monitoring are:
From the Azure portal, you can view the Azure AD Audit logs and download as comma-separated value (CSV) or JavaScript Object Notation (JSON) files. The Azure portal has several ways to integrate Azure AD logs with other tools that allow for greater automation of monitoring and alerting:
Microsoft Sentinel – enables intelligent security analytics at the enterprise level by providing security information and event management (SIEM) capabilities.
Sigma rules - Sigma is an evolving open standard for writing rules and templates that automated management tools can use to parse log files. Where Sigma templates exist for our recommended search criteria, we've added a link to the Sigma repo. The Sigma templates aren't written, tested, and managed by Microsoft. Rather, the repo and templates are created and collected by the worldwide IT security community.
Azure Monitor – enables automated monitoring and alerting of various conditions. Can create or use workbooks to combine data from different sources.
Azure Event Hubs -integrated with a SIEM- Azure AD logs can be integrated to other SIEMs such as Splunk, ArcSight, QRadar, and Sumo Logic via the Azure Event Hubs integration.
Microsoft Defender for Cloud Apps – enables you to discover and manage apps, govern across apps and resources, and check your cloud apps’ compliance.
Securing workload identities with Identity Protection Preview - Used to detect risk on workload identities across sign-in behavior and offline indicators of compromise.
Much of what you'll monitor and alert on are the effects of your Conditional Access policies. You can use the Conditional Access insights and reporting workbook to examine the effects of one or more Conditional Access policies on your sign-ins, and the results of policies including device state. This workbook enables you to view a summary, and identify the effects over a specific time period. You can also use the workbook to investigate the sign-ins of a specific user.
The rest of this article describes what we recommend you monitor and alert on, and is organized by the type of threat. Where there are specific pre-built solutions we link to them or provide samples following the table. Otherwise, you can build alerts using the preceding tools.
Device registrations and joins outside policy
Azure AD registered and Azure AD joined devices possess primary refresh tokens (PRTs), which are the equivalent of a single authentication factor. These devices can at times contain strong authentication claims. For more information on when PRTs contain strong authentication claims, see When does a PRT get an MFA claim? To keep bad actors from registering or joining devices, require multi-factor authentication (MFA) to register or join devices. Then monitor for any devices registered or joined without MFA. You’ll also need to watch for changes to MFA settings and policies, and device compliance policies.
What to monitor | Risk Level | Where | Filter/sub-filter | Notes |
---|---|---|---|---|
Device registration or join completed without MFA | Medium | Sign-in logs | Activity: successful authentication to Device Registration Service. And No MFA required |
Alert when: Any device registered or joined without MFA Microsoft Sentinel template Sigma rules |
Changes to the Device Registration MFA toggle in Azure AD | High | Audit log | Activity: Set device registration policies | Look for: The toggle being set to off. There isn't audit log entry. Schedule periodic checks. Sigma rules |
Changes to Conditional Access policies requiring domain joined or compliant device. | High | Audit log | Changes to CA policies |
Alert when: Change to any policy requiring domain joined or compliant, changes to trusted locations, or accounts or devices added to MFA policy exceptions. |
You can create an alert that notifies appropriate administrators when a device is registered or joined without MFA by using Microsoft Sentinel.
Sign-in logs
where ResourceDisplayName == "Device Registration Service"
where conditionalAccessStatus == "success"
where AuthenticationRequirement <> "multiFactorAuthentication"
You can also use Microsoft Intune to set and monitor device compliance policies.
Non-compliant device sign-in
It might not be possible to block access to all cloud and software-as-a-service applications with Conditional Access policies requiring compliant devices.
Mobile device management (MDM) helps you keep Windows 10 devices compliant. With Windows version 1809, we released a security baseline of policies. Azure Active Directory can integrate with MDM to enforce device compliance with corporate policies, and can report a device’s compliance status.
What to monitor | Risk Level | Where | Filter/sub-filter | Notes |
---|---|---|---|---|
Sign-ins by non-compliant devices | High | Sign-in logs | DeviceDetail.isCompliant == false | If requiring sign-in from compliant devices, alert when: any sign in by non-compliant devices, or any access without MFA or a trusted location. If working toward requiring devices, monitor for suspicious sign-ins. |
Sign-ins by unknown devices | Low | Sign-in logs | DeviceDetail is empty, single factor authentication, or from a non-trusted location | Look for: any access from out of compliance devices, any access without MFA or trusted location Microsoft Sentinel template Sigma rules |
Use LogAnalytics to query
Sign-ins by non-compliant devices
SigninLogs
| where DeviceDetail.isCompliant == false
| where conditionalAccessStatus == "success"
Sign-ins by unknown devices
SigninLogs
| where isempty(DeviceDetail.deviceId)
| where AuthenticationRequirement == "singleFactorAuthentication"
| where ResultType == "0"
| where NetworkLocationDetails == "[]"
Stale devices
Stale devices include devices that haven't signed in for a specified time period. Devices can become stale when a user gets a new device or loses a device, or when an Azure AD joined device is wiped or reprovisioned. Devices might also remain registered or joined when the user is no longer associated with the tenant. Stale devices should be removed so the primary refresh tokens (PRTs) cannot be used.
What to monitor | Risk Level | Where | Filter/sub-filter | Notes |
---|---|---|---|---|
Last sign-in date | Low | Graph API | approximateLastSignInDateTime | Use Graph API or PowerShell to identify and remove stale devices. |
BitLocker key retrieval
Attackers who have compromised a user’s device may retrieve the BitLocker keys in Azure AD. It's uncommon for users to retrieve keys, and should be monitored and investigated.
What to monitor | Risk Level | Where | Filter/sub-filter | Notes |
---|---|---|---|---|
Key retrieval | Medium | Audit logs | OperationName == "Read BitLocker key" | Look for: key retrieval, other anomalous behavior by users retrieving keys. Microsoft Sentinel template Sigma rules |
In LogAnalytics create a query such as
AuditLogs
| where OperationName == "Read BitLocker key"
Device administrator roles
Global administrators and cloud Device Administrators automatically get local administrator rights on all Azure AD joined devices. It’s important to monitor who has these rights to keep your environment safe.
What to monitor | Risk Level | Where | Filter/sub-filter | Notes |
---|---|---|---|---|
Users added to global or device admin roles | High | Audit logs | Activity type = Add member to role. | Look for: new users added to these Azure AD roles, subsequent anomalous behavior by machines or users. Microsoft Sentinel template Sigma rules |
Non-Azure AD sign-ins to virtual machines
Sign-ins to Windows or LINUX virtual machines (VMs) should be monitored for sign-ins by accounts other than Azure AD accounts.
Azure AD sign-in for LINUX
Azure AD sign-in for LINUX allows organizations to sign in to their Azure LINUX VMs using Azure AD accounts over secure shell protocol (SSH).
What to monitor | Risk Level | Where | Filter/sub-filter | Notes |
---|---|---|---|---|
Non-Azure AD account signing in, especially over SSH | High | Local authentication logs | Ubuntu: monitor /var/log/auth.log for SSH use RedHat: monitor /var/log/sssd/ for SSH use |
Look for: entries where non-Azure AD accounts are successfully connecting to VMs. See following example. |
Ubuntu example:
May 9 23:49:39 ubuntu1804 aad_certhandler[3915]: Version: 1.0.015570001; user: localusertest01
May 9 23:49:39 ubuntu1804 aad_certhandler[3915]: User 'localusertest01' is not an AAD user; returning empty result.
May 9 23:49:43 ubuntu1804 aad_certhandler[3916]: Version: 1.0.015570001; user: localusertest01
May 9 23:49:43 ubuntu1804 aad_certhandler[3916]: User 'localusertest01' is not an AAD user; returning empty result.
May 9 23:49:43 ubuntu1804 sshd[3909]: Accepted publicly for localusertest01 from 192.168.0.15 port 53582 ssh2: RSA SHA256:MiROf6f9u1w8J+46AXR1WmPjDhNWJEoXp4HMm9lvJAQ
May 9 23:49:43 ubuntu1804 sshd[3909]: pam_unix(sshd:session): session opened for user localusertest01 by (uid=0).
You can set policy for LINUX VM sign-ins, and detect and flag Linux VMs that have non-approved local accounts added. To learn more, see using Azure Policy to ensure standards and assess compliance.
Azure AD sign-ins for Windows Server
Azure AD sign-in for Windows allows your organization to sign in to your Azure Windows 2019+ VMs using Azure AD accounts over remote desktop protocol (RDP).
What to monitor | Risk Level | Where | Filter/sub-filter | Notes |
---|---|---|---|---|
Non-Azure AD account sign-in, especially over RDP | High | Windows Server event logs | Interactive Login to Windows VM | Event 528, log-on type 10 (RemoteInteractive). Shows when a user signs in over Terminal Services or Remote Desktop. |
Next steps
Azure AD security operations overview
Security operations for user accounts
Security operations for consumer accounts
Security operations for privileged accounts
Security operations for Privileged Identity Management