NOTE (April 13th, 2021): I’ve updated the content of this blog post as part of the “Azure AD Attack and Defense” playbook. You’ll find the latest version here

Identity Security Monitoring in a Hybrid Environment

In the recent year, I‘ve talked about monitoring of Azure Active Directory in community sessions and talks. From my point of view a comprehensive monitoring of “identity security events must be an essential part of deployment plans and daily operations. Even though it may seem obvious as „best practice“ („Actively monitor for suspicious activities“), it is sometimes underrated.

Monitoring across “Azure AD” and “Active Directory” (including spreading between workloads in Azure and on-premises environments) can be complex and sometimes challenging but more important then ever. Identity protection in a “hybrid world” means also to protect and monitor Active Directory environments with all existing risks and traditional attack methods (e.g. “Pass-the-Hash”). The weakest link and uncover attack surfaces in your on-premises environment can be used to leverage or extend attacks to (hybrid) cloud services.

../2020-12-16-identity-security-monitoring/AzIdentity_Security.png “Microsoft Defender for Identity” (MDI), “Microsoft Cloud App Security” (MCAS) and “Azure AD Identity Protection” protects identities on various levels and platforms (On-Premises, Session/Cloud Apps and Cloud Identity/Sign-ins)

Implementing “identity security” does not end with „enabling“ those features or by following the recommendations by „Identity Secure Score“…

It’s important to develop a “continuous improvement” strategy of detections and “operational guide” to empower and monitor your signals of „guards“. This includes also to provide workflows for automated response, an “unified view” for incident management/hunting, security processes and posture management.

Extensive possibilities of “User and Entity Behavior Analytics” (UEBA) allows SecOps to find anomalous activities (calculated by machine learning algorithms) across the various data sources or signals instead of building a manual correlation.

At always, keep up-to-date and notified about latest changes of security features, attack/defense scenarios or security recommendations. Verification of effectiveness by “simulated attacks” should be also part of your operational tasks.

This blog post is an attempt to give a detailed overview on solutions to collect identity-related security events and implement auto-response on threads or risks. Many links to detailed documentation by Microsoft and members of the community are included. There is no claim for completeness and comprehensive view of all options. I’ve tried to find some “sample use cases” to underline when this monitoring option will be in particularly relevance. It was hard for me to find the right level of details or scope with regard to the wide-range of this topic.

The following objectives are excluded and out of scope: Azure AD B2C, Azure AD Domain Services and Microsoft Information Protection (AIP/MIP) will not be described in this blog post.

Caution: All description of features, potential limitations and implementation considerations are based on personal experiences and research results at the time of writting this blog post. Therefore the content and statement can be outdated since the article was published in December 2020.

Note: Microsoft announced many product name changes at the Ignite 2020. I’ve used all new product names in this article. A good overview of all name changes are included in this blog post by Microsoft.

Azure Monitor: Operational Logs and Alerts of Azure AD and Azure Workloads

Sample use case: Security Operation Teams (SecOps) manages Microsoft Azure workloads only (no M365 services) and needs an “unified view” of Azure Services and Azure AD security events. No hybrid identity (Windows Server Active Directory) or hybrid cloud (Google Cloud, AWS) scenarios.

../2020-12-16-identity-security-monitoring/AzIdentity_AzMonitor.png

Data Sources of “Azure Monitor Logs”

IaaS/PaaS (Cloud and on-Premises) in “Azure Monitor”

Azure Monitor allows you to collect logs from the Azure platform and resources for visualization and alerting or forwarding to other destination (for long-term retention or advanced scenarios). In this use case we are using Microsoft “Log Analytics” to enable advanced (KQL-based) queries and centralized collection of logs. The following data sources should be considered to collect relevant information for your IAM security monitoring:

Azure Security Center (ASC) and “Azure Monitor”

Continous Export allows to forward alerts and recommendations to “Azure Event Hub” or “Log Analytics”. This solution is divided in two different scopes: Free service “Security Center” as “Cloud security posture management (CSPM)” solution. Azure Defender as “Cloud workload protection (CWP)” add-on with licensing option to pay only for what you use.

Cloud Identity (Azure Active Directory) in “Azure Monitor”

Routing of Azure AD activity logs is natively supported to various targets such as Azure Event Hub, Blob Storage and Log Analytics.

Supported reports in Azure Monitor

Non-supported reports in Azure Monitor

  • Azure AD (Identity Protection) Security Logs: Identity Protection of Azure AD Premium stores reports and events of risky users, sign-ins (up to 30 days) and detections (up to 90 days).
    • Various “risk detections” are available which will be calculated in real-time or offline. Risk state triggers “auto-response actions” and offers “self-remediation options” that will be managed by identity protection policies or as part of Conditional Access Policies.
    • Microsoft Graph APIs allows you to collect this data for export or automate response to risk detections.

    • Every Azure AD Sign-in log includes the following properties related to the identity risk detection: riskDetail, riskLevelAggregated, riskLevelDuringSignIn, riskState, riskEventTypes.

      ../2020-12-16-identity-security-monitoring/AzIdentity_AzMonitor_IPCDetection.png Risk detections from “Cloud App Security” (such as “Impossible Travel”) will be also displayed in the “Identity Protection” blade (Azure portal). Correlation between sign-in event and offline detections by Identity Protection (in this sample “Password Spray, Malicious IP address and Atypical travel) can be established by Request or CorrelationID.

      ../2020-12-16-identity-security-monitoring/AzIdentity_AzMonitor_IPCQuery.png Collected “sign-in events” in “Azure Monitor Logs” will be enriched with “RiskState” and “RiskLevelDuringSign” if a risky sign-in was detected (in real-time or sign-in attempt was made after risk detection).

Log Collection (via “Azure Monitor”)

  • Log Analytics: Azure’s native “Log Management Solution” enables deep analytics and advanced queries in case of troubleshooting or technical investigation. Kusto (KQL) is the query language that you should use (and learn). This is the foundation of many features and primary query language in solutions such as as “Azure Sentinel” (built on top of Log Analytics) or “Azure AD Workbooks” (sourced log data from a workspace). Other monitoring solutions in the “Azure platform” are using also “Log Analytics workspaces” to store data (e.g. App Insights).

Analyze and Visualize with “Azure Monitor”

  • Azure AD Workbooks: Microsoft provides built-in visualization which requires Log Analytics workspace. They are very helpful to analyze (and troubleshoot) activities around Authentication, Conditional Access and other identity-related operations.
  • Azure AD Dashboards: Azure AD Dashboard views are available for “Account Provisioning” and “Sign-In Events” but seems little bit outdated.
  • Usage and Insights: An overview about registered/usage of “authentication methods” and “Azure AD-integrated apps” activity are available in the “Azure Portal”. These usage statistics are also available via “Microsoft Graph API”. The following sample script analyse the statistics to make recommendations.
  • Log Analytics Solutions:
    • AD Health Check: Optimize your Active Directory environment with the “Active Directory Health Check” solution in Azure Monitor
    • AD Replication Status: Monitor your “Active Directory replication status” with Azure Monitor

Integration and Response in “Azure Monitor”

Considerations and References of Azure AD Logging by “Azure Monitor”

MCAS and “Defender for Identity”: Unified SecOps of connected “Cloud Apps” and “Hybrid Identity”

../2020-12-16-identity-security-monitoring/AzIdentity_MCAS.png

Sample use case: SecOps that manages security of cloud platforms or SaaS solutions and need an unified view for investigation or alerting on (hybrid) identities.

Data Sources in MCAS

IaaS/PaaS (Cloud and on-Premises) in MCAS

MCAS allows you to connect Microsoft‘s Azure platform and other cloud platform provider (AWS and Google Cloud Platform) via “App Connector”. This makes the „Activity logs“ available in MCAS for investigation and trigger alerts. The security configuration of “Google Cloud” and “Amazon Web Services” (AWS) can be integrated to provide fundamental security recommendations based on the CIS benchmark.

Azure Security Center (ASC) and MCAS-Integration

Security Configuration Assessment results of MCAS will be collected from the “Azure Security Center”. This gives you a common view of the security posture, usage of cloud resources and suspicious activities across your cloud infrastructure assets (in Microsoft Azure).

Cloud Identity in MCAS

Azure AD audit and sign-in events are covered by the „Office 365 connector“ in MCAS. But only interactive sign-in activities and sign-in activities from legacy protocols seems to be included. Advanced categories such as “Service Principals” aren’t covered by the connector (yet).

../2020-12-16-identity-security-monitoring/AzIdentity_MCAS_IPCAlerts.png All “Identity Protection” risk detections will be listed in the MCAS alerts view.

On-Premises Identity (Active Directory) in MCAS

Microsoft Defender for Identity (MDI) allows you to detect and identify attacks in your “on-premises environment”. It‘s based on monitoring and profiling of user behavior and activities. MDI includes the detection of Lateral Movement Paths (LMP) which is strongly recommended to consider. Keep in mind, machine-learning on user/entity-related behavioral needs a learning period.

  • Security Alerts are categorized in phases of the “CyberAttack kill-chain” and are well documented by Microsoft.
  • Integration of MDI with Defender for Endpoint allows you to laverage the detection from events of the domain controller to all endpoints. Furthermore it allows you to see open MDI alerts as badge in the MDE portal.

  • Integration of MDI with MCAS is mandatory for environments where both solutions are in use. More and more features around MDI seems to be moved to the MCAS portal (such as the new “hunting experiences”). All activities and detections of MDI will be also included in the UEBA if integration is configured.

    ../2020-12-16-identity-security-monitoring/AzIdentity_MCAS_MDIPortal.png Attacks on Active Directory (On-Premises) will be detected by MDI and generates an alert in the MDI portal.

    ../2020-12-16-identity-security-monitoring/AzIdentity_MCAS_MDIAlertInMCAS.png New “hunting experience” allows to use MCAS portal for unified incident management between “Active Directory” and “Azure AD” alerts.

    • MCAS is using MDI data as source to collect activities from Active Directory as an „app“. This gives you an “unified activity” overview of an user in “Azure AD”, “Active Directory” and “MCAS connected apps”.

    ../2020-12-16-identity-security-monitoring/AzIdentity_MCAS_UnifiedFailedLogins.png Example: Failed sign-in attempts to Active Directory or connected apps (in this case, “Azure Portal” and “Office 365”).

  • All alerts and events of MDI can be exported in CEF format.
  • Regular updates are adding new detection methods that raised up. A good example is the vulnerability detection of ZeroLogon which was introduced in November 2020.
  • Details on managing and investigation are very well documented in a TechCommunity blog article about “daily operation of MDI”. Another article in this series describes details on “Deployment and Troubleshooting”.

Cloud Session Monitoring by Cloud App Security

Microsoft Cloud Access Security Broker (CASB) enables you to identify usage of cloud apps, insights of risk assessments and capabilities to control the sessions and access to the cloud apps. There are some features that are essential for monitoring your identities and their access to sanctioned or unsanctioned resources or apps:

  • “Cloud Discovery” allows you to detect usage of cloud apps from proxy/firewall logs or machine-based discovery (from MDE). Integrated “Cloud App Catalog” shows a “risk score” and detailed information (security factors, industry- and legal regulations) to discovered apps. Classification as “unsanctioned” will start blocking the usage of the app.
  • MCAS provides “App Connectors” for some cloud provider to get advanced visibility and protection of sanctioned/connected apps. Insights of user/access management, activity logs and file/sharing control will be collected via “API connections” to the supported cloud products (GitHub Enterprise, ServiceNow, etc.).
  • Sessions to Azure AD-integrated apps can be managed (for limited access) in MCAS with “Conditional Access App Control”. MCAS acts as a reverse proxy to control sessions of the configured cloud app. This gives you various compliance options such as preventing data exfiltration or real-time monitoring of user activity (anomalies) in the session.

../2020-12-16-identity-security-monitoring/AzIdentity_MCAS_CloudSessionAlerts.png MCAS allows to get insights of suspicious user behavior in the session to a connected cloud app (such as download/upload to OneDrive and SharePoint). Custom activity alerts are also possible (like in this example, activity by “Global Admin to gain elevated access to Azure Management scope”).

Collaboration Platforms (Office 365 Services) in MCAS

Microsoft‘s Office 365 but also other collaboration platforms (Dropbox and G-Suite) or SaaS provider can be connected via “app connectors”. This gives you options to visibility, governance and protection of those services. Level of centralized management in MCAS depends on abilities that are supported by the connector.

  • App Connector of “Office 365” will be also used to source the following “Azure AD” information and are prerequisites for the identity monitoring capabilities in MCAS:
    • Azure AD Users and groups (Meta information of those objects in the tenant)
    • Azure AD Management events (Audit Logs)
    • Sign-in events (Interactive Sign-in activities and activities from legacy protocols such as ActiveSync)
    • Azure AD Apps (registered “OAuth” apps)
  • Audit data will be ingested from the “Office 365 Management Activity API”. A deep dive description of collecting this audit events are very well described in a blog post by Sami Lamppu. In general, the audit log from “Office 365 Security and Compliance Portal” shows the same level of information as the activity log from the MCAS “app connector”.
  • Alerts of “Microsoft Defender for Office 365” (MDO) are also visible in the “MCAS Activity Log” and allows you to create custom policies in MCAS. Sami Lamppu has also given some details about this in one of his blog posts.

Device / Endpoint Security (Microsoft Defender for Endpoint) Integration in MCAS

“Microsoft Defender ATP” (MDATP) Portal was rebranded to “Microsoft Defender Security Portal” in the fall of 2020. Microsoft’s Endpoint and Detection and Response (EDR) solution allows deep integration to MCAS. But also insights from MCAS will be displayed in the (new) Endpoint Security Portal.

Signal forwarding from “Microsoft Defender for Endpoint” (MDE) to MCAS is an essential configuration to establish the visibility of “cloud app usage” and control of unwanted apps (as described previously). But it’s also extend the “MCAS Discovery Dashboard” with an additional “machine-centric” view. This allows you to start investigation based on a specific machine and correlate statistics of risky apps, transaction/traffic and device risk (calculated by MDE) right from MCAS. A direct (deep) link to the machine object helps to continue the investigation in the “Microsoft Defender Security Center” (MDE Portal).

Analyze and Visualize with MCAS

User and Entity Behavior Analytics (UEBA) in MCAS

  • (Hybrid) Identity Threat Investigation: The “user page” in MCAS gives you an overview and correlated information from all connected apps or integrated “threat protection solutions” in a single view. This is also a landing page to get all related and collected information about activities (from the “Activity Log”), alerts (filtered by selected user) or actions by policies (“Governance Log”). User Exposure information shows summary from various sources (e.g. number of accounts that are correlated by app connector). Activities of the users can be filtered and will be enriched by MCAS (such as Internal/External users, Status as admin account or critical role/group assignment).
    • User page and “hunting experiences” in “Microsoft Defender for Identity” will be probably moved to the MCAS portal.
    • Device page is also available for all MDI device objects and shows open alerts and summary of activities (logged on users, resource access, IPs)
  • Investigation Priority Score: This score helps to identify the riskiest users across the various signals, alerts and integrations. Therefore, the “Investigation Priority” pulls together signals from connected apps and integrated threat protections (MDI and “Azure AD Identity Protection”) to find abnormal behavior and aggregate this into a single score value. This score will be displayed on the “MCAS dashboard” and in the user page for further investigation.
    • Matt Soseman has recorded a YouTube video about it which includes the calculation of the score and some demo on investigation in the “UEBA”.
    • Consider to tune the policies for anomaly detection and review the default governance actions after enabling the data sources (threat protections, connected apps and discovery logs).

    ../2020-12-16-identity-security-monitoring/AzIdentity_MCAS_UEBA.png Alerts and activities of the last 7 days will be shown in the user page only. “Investigation priority” only considered the threats within this time range. So keep in mind, the total number of “open alerts” in the “user threat” panel.

Identity Security Posture and Apps Inventory with MCAS

Integration and Responds in MCAS

  • Policies: Control of your identities in connected apps/resources can be achieved by monitored activities and signals by MCAS. The following types of policies can be configured:
    • Access Policies gives you the ability for real-time monitoring and control the access on your “connected apps”. The applied actions (“Monitor” or “Block”) can be filtered on advanced criteria such as device tags, source of access (IP address), client app or user/app scope.
    • Session Policies enables real-time action and monitoring within the session and allows to block or restrict on specific activities (such as sharing or file control).
    • Activity Policies enforces automated response on a specific or repeated activity to a connected app. As a response, governance actions can enforce security mechanism on API level by “connected app” (e.g. require sign-in prompt in Office 365), user account state in Azure AD (e.g. disable user) or custom playbook (PowerAutomate). Activities of tasks that is performed by a user or admin of your Azure AD tenant.
    • Anomaly Detection Policies are enabled to find unusual activities and trigger an alert if unusual behavior was detected (different from user’s regular activity). They are part of the UEBA and ML capabilities which are integrated in MCAS and displayed in the “User Page” / “Investigation Priority Score”. Built-in policies covers activities from specific activities in a connected app (e.g. connected “Azure Instance” and “Multiple delete VM activities”) to find anomalies of a single user session (“Unusual activities by user”). Some anomaly detection policies can be tuned or scoped to adjust sensitivity or customize automated response.

    ../2020-12-16-identity-security-monitoring/AzIdentity_MCAS_Governance.png Governance log shows actions (initiated by policies) of automated response on alerts (such as require user to sign-in again if a risky sign-in was detected).

  • Policy Templates: Before creating your own policies, check the built-in templates in MCAS that are ready for use. Many of them are essential and strongly recommended to be enabled and configured in your MCAS instance.
  • PowerAutomate: Automation of (governance) actions can be realized by “PowerAutomate”. Microsoft has released some sample playbooks for auto-remediation or -response scenarios on GitHub.

Considerations and References of “Cloud App Security”

  • Interaction, integration and options of MCAS with other services in “Microsoft 365” are numerous and plays a significant role. Check out MCAS design diagram (by ManagedSentinel.com) to get an overview of those connections.
  • Regular check of “MCAS Changelog” should be made to be informed about changes in your tenant and new features or risk detection.
  • MCAS allows to gain sensitive information about a user which includes files, used cloud apps and all activity logs from connected apps. Therefore you should verify with your “IT Compliance and Data Privacy Department” if anonymizing of user data is required (to protect user privacy). Currently this feature is limited to user and machine names.
  • Service health can be monitored on the “MCAS status page” and should be integrated for notification of service issues or delays of detections
  • Daily operational tasks for MCAS are documented by Microsoft.
  • Consider Microsoft’s best practices of implementing MCAS in your environment
  • Governance Actions (by activity policies) must be in accord with your Azure AD environment.
    • Example: Suspended user will be reactivated after next Azure AD Connect sync interval.
  • MCAS API can be easily discovered and tested by using the postman collection (from Rich Lilly).
  • Office 365 App Connector needs at least one assigned licensed user even if you want to use it to collect all Azure AD events only.
  • Implement a process and simulate investigation of anomaly detection alerts!
  • MCAS is very useful and efficient to monitor suspicious privileged tasks in Azure.
    • Elevated Global Admin permissions on Azure Management (as already mentioned in the sample) is one of the use cases which can be (as far as I know) only be monitored by MCAS. Sami Lamppu has written a detailed blog post about it!
  • RBAC in MCAS doesn’t allow assignment of roles to Azure AD groups (only users are supported).
  • Scoped deployment can be very useful in setting up “Proof-of-Concept” environment or staged roll-outs in production
  • Currently, blocking access to Cloud apps by (custom) indicators in “Microsoft Defender for Endpoint” (MDE) has some limitations:
    • MDE allows 15.000 indicators per tenant
    • This feature is supported on Windows 10 only (no support for ATP on MacOS or Linux yet)
  • Detailed training on MCAS features are available as “Ninja Training”

Considerations and References of Microsoft Defender for Identity (MDI)

  • Check alerts for false-positive events (“DCSync Attack”) of “Azure AD Connect” server (exclude them for this specific detection).
  • Signature-based capabilities can be evaluated as part of the “Defender for Identity security alert lab”. Simulation of “Lateral Movement Attacks” is recommended and described in the blog post (by Derk van der Woude).
  • By default, some domains are excluded from detections (Example: spotify.com)!
  • Audit Policy of domain controllers must be configured to maximize detection capabilities. Using this PowerShell script should helps you to verify the configuration.
  • Review the known issues and limitations of MDI sensors and detections
  • Currently there’s no option to collect Sensor health status!
  • Global and Security Administrator are assigned with MDI “Administrator” permission by design. Default “Azure AD security groups” (“Azure ATP Administrator/Users/Viewers") can be used to delegate permissions on the [MDI RBAC model](https://docs.microsoft.com/en-us/defender-for-identity/role-groups#types-of-product-short-security-groups). Modification of those group membership should be monitored for prevention of access to security sensitive logs or disabling the sensor/detection.
  • I can only recommend to review the list of “sensitive accounts and groups” and add non-builtin privileged objects (incl. hybrid identity components such as “Azure AD Connect” and the service accounts).
  • Subscribe the RSS feed of “What’s new” to be notified about product changes and new features
  • Service health can be monitored on the MDI status page and integrated for notification of service issues or delays of detections. Consider to actively monitor the sensors in your infrastructure.
  • Sizing tool and capacity planing guidance of MDI should be used in the planning phase to calculate amount of traffic, supportability and resource recommendations for sensors.

Microsoft 365 Defender: Unified SecOps of M365 Services

Sample use case: SecOps needs a unified visibility of logs and possibility of hunting across all “Microsoft 365” services and assets (data, identity, endpoints and cloud apps). Consolidated view on logs and summarized incidents from all “M365 Defender” services with enriched data is needed. Using centralized investigation of recorded activities (telemetry) in M365 services and empowering built-in (auto)-remediation of incidents by “Automated Investigation and Response (AIR) System”.

../2020-12-16-identity-security-monitoring/AzIdentity_AzMonitor.png

Microsoft 365 Defender (formerly “Microsoft Threat Protection”) supports various services from the “M365 platform”. Check the “supported services” list to understand which data sources can be integrated. Start using “M365 Defender” is very easy by “turn on” the described setting in the “Microsoft 365 Security Center”.

Data Sources in “M365 Defender”

IaaS/PaaS (Cloud and on-Premises) and “M365 Defender”

Azure resource-level or collected logs by Azure Monitor are not covered by “M365 Defender”. Example: Event logs of Azure/Hybrid Servers or alerts from Azure Defender are not visible for hunting in this portal.

Cloud Identity (Azure Active Directory) in “M365 Defender”

Incidents / AlertInfo: Risk detections from “Azure AD Identity Protection” seems to be not included in the “Incidents” and aren’t visible in the table “AlertInfo”. MCAS feeds many type of alerts to “M365 Defender” and “sign-in risk events” (detected by MCAS) is one of them. MCAS will be named as “ServiceSource” and “DetectionSource” in the log entries. Nevertheless, alerts from the “Risky sign-in” policy in MCAS, which collects also all “Identity Protection” risks (detected by “AAD Identity Protection”), can not be founded in “M365 Defender”.

Examples:

  • “Password Spray” will be detected by “Identity Protection” and listed in MCAS as “Risky sign-in” (as you have seen in the screenshots of previous article section). But it is not visible in the “AlertInfo” table or as part of an Incident in “M365 Defender”.

  • “Impossible Travel” is detected by MCAS and will be shown in the “Identity Protection” blade of Azure AD. But this risk detection is also listed as MCAS alert (“Impossible travel activity”) and will be shown in the “Incident” view of “M365 Defender” and exists in the “AlertInfo” table.

    ../2020-12-16-identity-security-monitoring/AzIdentity_MTP_Incidents.png Alerts from MCAS (and MDI) will be summarized as “Incidents” in the “M365 Security Portal”. Detections by “Azure AD Identity Protection” (e.g. Password Spray) are missing. Alerts from connected apps in MCAS are also not listed in this case (e.g. “Mass Download” from OneDrive or SharePoint) or custom activity alerts (e.g. Elevated GA to Azure Management in Azure Portal).

    ../2020-12-16-identity-security-monitoring/AzIdentity_MTP_MCASAlerts.png In comparison with the list of alerts in MCAS, not existing alerts in “M365 Defender” are bordered in red.

IdentityLogonEvents: Authentication events captured by MCAS will be stored in this table. This seems to covers only “sign-in events” to connected apps and are similar to the “Activity Logs” in the MCAS blade (filtered by “Successful or failed login-ins”). As already described, “non-interactive” logons or sign-ins by “service principal”/”managed identity” are not covered.

IdentityInfo: Account information from various identity sources (including “Active Directory” and “Azure AD”) will be stored here, to enable build relation between user objects (e.g. ObjectID, “On-Premises SID” and “Cloud SID”). Other details such as DisplayName, ProxyAddress or Account Status are also included.

UPDATE (Dec 18th): Azure AD audit logs are now integrated in M365 Defender for advanced hunting. Events will be streamed from the “Office 365 connector” and log data is available in the CloudAppEvents table.

On-Premises Identity (Active Directory) in “M365 Defender”

It’s important to know that data of “Microsoft Defender for Identity” (MDI) will only be shown in the “M365 Defender” portal if the integration between MCAS and MDI is enabled. MCAS seems to be responsible to feeds the related MDI data to “M365 Defender”.

Correlation of MDI alerts with other activities and alerts from “M365 Defender” services (such as “Microsoft Defender for Endpoint”) gives you new capabilities to understand the context of Active Directory attacks. This becomes obvious if you think about the limited visibility of endpoint (threats) in MCAS.

Recently, Microsoft added the opportunity to use “Advanced Hunting” based on events captured by MDI. Another benefit (compared to MDI queries in the MCAS portal): Writing KQL queries for advanced hunting in “M365 Security Portal” by using the advanced logs from the following tables:

AlertInfo: Alerts from MDI will be stored in this table. AlertId includes the prefix “aa” (stands for Azure ATP?) followed by the original “AlertId” from the MDI portal (not the MCAS AlertID!).

IdentityInfo: As already described before, this table helps to correlate and build relation between various account objects. In this case, very helpful for advanced hunting and queries between “Azure AD” and “Active Directory” user objects.

IdentityLogonEvents: Authentication events to your “Active Directory” will be stored in this table. The logon events will be sourced from the connected MDI instance in MCAS and shows similar results to a filtered “Activity Log” (by “Active Directory” app in the MCAS portal). Various types of logon events in “Active Directory” are covered (including Remote Desktop, Interactive and Credentials validation via NTLM/Kerberos). Failure reason of “sign-in attempts” are also included (e.g. OldPassword).

IdentityQueryEvents: Queries on Active Directory objects (such as LDAP, DNS and SAMR) are collected from MDI in this table.

IdentityDirectoryEvents: This table contains many identity-related (on-premises) audit and system events from the domain controller. User-level auditing of password or group memberships are included but also “domain controller events” such as PowerShell execution, Task scheduling or potential lateral movement.

Cloud Sessions (Microsoft Cloud App Security) in “M365 Security”

Cloud Discovery and activity logs from connected apps are not available for hunting in “M365 Defender”.

DeviceNetworkEvents: As already described, “Microsoft Defender for Endpoints” (MDE) can be configured to forward signals to MCAS (for “Cloud Discovery” and “Visibility of (un)sanctioned cloud apps”). This table helps to start queries on the raw logs from MDE.

Collaboration Platforms (Office 365 Services)

AlertInfo: Threat protection signals and data will be correlated from “Microsoft Defender for Office 365” (MDO) in M365 Defender. But it’s limited to features and alerts around “Exchange Online” (such as “Safe Links” or Attachments).

Other Exchange Online-related logs and events are stored in the following tables and could be relevant for hunting of phishing mails:

CloudAppEvents: Activities from “Exchange Online” and “Microsoft Teams” (monitored by MCAS) are available for hunting here. Other O365 services are not supported yet! OneDrive and SharePoint Online will be introduced in early 2021 and the existing “AppFileEvents” will be replaced at this time.

Device / Endpoint Security (Microsoft Defender for Endpoint) and “M365 Defender”

Integration of “Microsoft Defender for Endpoint” (MDE) enables visibility on endpoint states, raw events, detections and alerts (which includes EDR/AV/attack surface reduction) and entities related to devices in M365 Defender.

AlertInfo: Alerts from MDE will be shown in this table. Other events from this source will be stored in the following tables:

  • DeviceEvents (security controls such as AV or Exploit protection)
  • DeviceLogonEvents (logon events on/to devices from local or (Azure) AD users)
  • DeviceInfo (similar to the approach of the table “IdentityInfo”, helps to correlate or build relation based on meta information by devices)

M365 Defender provides a “Device profile page” which is accessible from the “Incident” view. This gives you a unified control on M365 Defender- and MDE-related actions.

Analyze and Visualize with “M365 Defender”

Monitoring and Reporting (“Cards” in M365 Security Home)

Dashboard of “Microsoft 365 Security Center” allows to add “cards” for summarized reports of various sections of security areas in “M365 Defender” (including “identity monitoring and reporting”).

Investigation of Incidents in “M365 Defender”

Incidents can be managed in the portal by adding comments, adjusting priority, reporting false/positives or checking related entities (devices/users) or alerts.

Suspicious entities are also stored in the table “AlertEvidence” which can be used for custom queries or advanced hunting.

Advanced Hunting in “M365 Defender”

As already described, “M365 Defender” supports hunting on query-based analytics (KQL) across the various tables from supported M365 services. This allows you easily to start hunting between activities and alerts of devices, e-mails and identities.

Custom Detections with “M365 Defender”

Advanced Hunting queries can be used to create a “Detection Rule” for alerting. This gives you the ability to proactively monitor specific critical events or potential threats. Applicable actions can be triggered if an entity is founded in the query (for example: Isolate device in case of a “Brute Force” attack).

Integration and Response in “M365 Defender”

Auto-Investigation and Response (AIR)

M365 Defender supports only remediation actions on suspicious or malicious “Devices” or “Emails”. Pending (if approval is needed/configured) or completed actions are visible and can be managed in the “Action Center”. This incident response activities follows after an automated investigation by M365 Defender.

Automation level and scope for Endpoints can be configured in the “Microsoft Defender Security Center” (MDE Portal). Policies for Office 365 can be configured in the “M365 Security Center”.

Threat Experts

Advice by Microsoft’s Threat Experts can be requested directly from the “Incident” view. This is an additional service which can be enrolled for a 90-day-trial or on-Demand subscription (by Microsoft).

Considerations and References of “M365 Defender”

Azure Sentinel: “Single pane of glass” across Azure, Microsoft 365 and 3rd party (cloud) platforms

Sample use case: SecOps that needs a security visibility across all “Microsoft Cloud services” (Azure and M365) and (Hybrid/On-Premises) infrastructure. Extended possibilities for customization of auto-response, integration of “3rd party security tools” or implementation custom detections are required. Azure Sentinel empowers SIEM capabilities as part of a cloud-native and integrated security solution by Microsoft. Longer data retention of logs and alerts, out-of-the-box detections and visualization are further advantages.

../2020-12-16-identity-security-monitoring/AzIdentity_AzSentinel.png

Data Sources of “Azure Sentinel”

All of the following data sources can be connected to “Azure Sentinel” by data connectors. Alerts from the Microsoft Security products can be created as “Incident” automatically which is strongly recommended to have been implemented (for unified incident view). Incidents generated by this products will be stored in the “SecurityIncident” table of the workspace.

Most of the following features can be used to visualize or extend the logs and alerts from data sources:

Note: Most of the KQL queries and dashboards are already integrated as “Templates” and available in your instance (right after the deployment). Nevertheless, I have added the links to the GitHub repository where you can find the original source of the templates.

IaaS/PaaS (Cloud and on-Premises) in “Azure Sentinel”

Azure Sentinel is built and will be deployed on “top of” Log Analytics Workspaces. Collection of security and audit logs from “Azure Resources” or servers (On-Premises or hosted by “3rd Party Cloud Providers”) can be implemented, alongside of the previously described “Azure Monitor (Logs)” integration. Azure Sentinel offers some “data connectors” to easily integrate the following data sources:

Azure Security Center (ASC) and “Azure Sentinel”

Alert Data from Azure Security Center (detected by Azure Defender): This connector allows to ingest alerts of detected threats by Azure Defender. The alerts will be found in the “SecurityAlert” table as ProviderName “Azure Security Center”.

Cloud Identity (Azure Active Directory) in “Azure Sentinel”

Data from Azure AD Logs: Audit and Sign-ins will be collected but no sign-in logs of “Service Principals”, “Non-Interactive” or “Managed Identities” are covered yet. Therefore you have to configure the “diagnostic settings” in the “Azure AD blade” manually to gather all insights of sign-in events to the workspace of Azure Sentinel.

Security Alerts from “Azure AD Identity Protection”: All risk detection will be stored in the “SecurityAlert” table under ProviderName “IPC” (= Identity Protection) by using this connector.

On-Premises Identity (Active Directory) in “Azure Sentinel”

Alerts from Microsoft Defender for Identity (MDI): Connector is listed as “Azure Advanced Threat Protection (Preview)” and forward the alerts to the “SecurityAlert” table (“ProviderName” is named like the previously product name).

  • Raw or detailed logs from MDI are not available in Azure Sentinel yet. Microsoft started to implement the “Microsoft 365 Defender” connector that seems to enable streaming of advanced logs in the future.

    ../2020-12-16-identity-security-monitoring/AzIdentity_AzSentinelM365Connector.png

    “Microsoft 365 Defender” connector allows to stream the already known “Advanced hunting” tables (with raw event data) from the “M365 Security Portal” to Azure Sentinel. Currently this is limited to “Defender for Endpoint” but seems to be coming for other M365 Defender products as well!

    But at this time, KQL-based queries and hunting (on detailed logs) are useable in “M365 Defender” only.

  • Collected (security) logs from domain controllers (via Log Analytics Agent / Azure Security Center) can be used to gain insights of the on-premises environment. Workbooks to analyze security events to detect usage of insecure protocols (NTLMv1, WDigest) or visualize anomalies and user activities across “Identity & Access” operations are available.

    ../2020-12-16-identity-security-monitoring/AzIdentity_AzSentinelWorkbookIAM.png Workbook template “Identity & Access” uses logs from the “SecurityEvents” table to visualize authentication events and user activities in your “Active Directory” environment.

Cloud Sessions (Microsoft Cloud App Security) in “Azure Sentinel”

Data from Cloud App Security: All alerts from MCAS will be stored in the table “SecurityAlert”. The second data type of the connector collects the “Discovery Log” (“Shadow IT” reports) from MCAS to the “McasShadowItReporting” table in the Sentinel workspace.

Collaboration Platforms (Office 365 Services) in “Azure Sentinel”

Data from Office 365 Logs: Activity logs from SharePoint, Exchange and Teams will be stored in the “OfficeActivity” table by this connector.

Alerts from “Microsoft Defender for Office 365” (MDO): Data connector is named as “Office 365 Advanced Threat Protection” (OATP) and allows to store many types of alerts from the “Office Security and Compliance Center” to the “SecurityAlert” table.

Advanced logs (data) and all types of alerts from MDO are not available yet. As already mentioned, the “M365 Defender Connector” seems to improve the log integration between MDO and Sentinel in the future.

Device / Endpoint Security (Microsoft Defender for Endpoint) in “Azure Sentinel”

Alerts from “Microsoft Defender for Endpoint” (MDE): Data connector to fetch alerts generated by endpoint protection is also named by the old brand “Microsoft Defender Advanced Threat Protection” (MDATP). Alerts will be also stored (similar to the other M365 Defender products) in the “SecurityAlert” table.

  • Many playbooks are available from Microsoft to use MDE to restrict entities (block IP address, URL, app execution,…) or further interaction (get investigation package or list of the Threat & Vulnerability Management) as part of an automated response process.

Data from M365 Defender (Device*): Advanced logs from the already known “advanced hunting” tables (DeviceInfo, DeviceLogonEvents,…) in “M365 Defender” will be streamed to “Azure Sentinel” by this new connector.

  • This allows new hunting and correlation options between logs that can be only collected from Azure Monitor/Azure Sentinel and M365 integrated logs.
    • Example: “Windows Sign-in events” (“SigninLogs” table, sourced from Azure AD) can be correlated natively with entries of the “DeviceLogonEvents” table which covers local sign-in and authentication events from MDE.
  • M365 Defender and Azure Sentinel are using KQL as query language. Therefore all your existing hunting queries from MDE/M365 Defender should be easily used in Azure Sentinel as well.

Investigation of Incidents in “Azure Sentinel”

Incidents and Workbooks in “Azure Sentinel” blade

Incidents blade of “Azure Sentinel” shows all alerts from the “connected data sources” in Azure Sentinel. This includes MCAS “custom alerts” (e.g. activity policy “Elevated Global Admin to Azure Management”) and all other built-in policies or detections (e.g. “Mass Download by a single user” in MCAS). But also alerts from “Azure Security Center” (“Access from a Tor exit”) and “Analytic rules” (from Azure Sentinel) on Azure Activity Logs (“Rare subscription-level operations”) will be listed.

../2020-12-16-identity-security-monitoring/AzIdentity_AzSentinelIncidents.png

It’s important to understand the difference between incident and alerts in Azure Sentinel: Incidents are a group of related alerts and will be correlated by Azure Sentinel.

  • As already described, alerts from connected security products (MDE, MDI, Azure Defender, etc.) are only displayed as “Incident” if “Microsoft Security Incident Creation Analytic Rules” are configured in the “Analytics” blade.
  • Built-in (templates) or custom analytic rules can be grouped as “Incident” if an alert is triggered (enabled by default).

It is also important to know the three different types of analytic rules and the logic behind them.

Templates of various workbooks are included that gives you an advanced view of incidents:

  • Incident Overview (In-depth information to a specific incident case)
  • Investigation Insights (timeline and trend of incidents combined with detailed information about entities)
  • MITRE ATT&CK (Visualizing coverage of “MITRE ATT&CK” framework on Azure Sentinel)

Investigation Graph

Investigation between security events based on “device” or “user” detections but also from “cloud” or “on-premises” resources can be hard. Sentinel offers a visualization of raw data and timeline to increase the visibility of context and helps to start your investigation on relation between entities of the incidents. Therefore, Investigation graph can be very useful for investigate your incidents.

Recently, Microsoft introduced the “Entity Insights” feature which shows detailed information of the related entities in the “investigation graph”.

../2020-12-16-identity-security-monitoring/AzIdentity_AzSentinelInvestigationGraph.png

Investigation starts on “Mass Download” incident and exploring all other related alerts from the entities. At the end, a comprehensive attack timeline and visualized progression of events will be shown. Detections of “Brute-Force” against “Active Directory” and the “Azure Portal” can be analyzed in the one investigation step.

Advanced multistage attack detection

Advanced multistage attack detection is based on machine learning (“Fusion” technology) and automates the correlation on various types of attack scenarios. This includes data exfiltration, lateral movement and malicious administrative activities.

../2020-12-16-identity-security-monitoring/AzIdentity_AzSentinelFusion.png Fusion detects a multistage attack and build an incident with collections of related alerts.

Entity Behavior

User Entity Behavior Analytics (UEBA) allows investigation of entities (such as user or devices) and their behavior based on Azure Sentinel data.

  • Onboarded data sources and their raw data will be analyzed by the “UEBA Engine” in Azure Sentinel to find anomalies.
  • User information will be synchronized from “Azure AD” to enrich user profiles in the UEBA entity pages.
  • Details on the architecture and engine to identify advanced threats with this feature are documented by Microsoft.

UEBA can be enabled from the “Entity behavior” blade in Azure Sentinel. Selection of data sources (used by UEBA) can also be configured in this blade and includes “Azure AD” (Audit / Sign-in logs), “Azure Activity” and “Security Events” (from all connected Microsoft Security products). Scoring and timeline of the “Entity pages” are longer visible in comparison with the MCAS “user page”.

Enriched events from the “UEBA engine” will be stored in the “BehaviorAnalytics” table and are readable as (table) entries by using KQL queries. Microsoft is also using this table to visualize “UEBA results” in the workbook template “User And Entity Behavior Analytics”. The founded anomalies will be scored with “Investigation Priority Score” and mapped to the “MITRE ATT&CK” framework.

Analytics from “UEBA” based on accounts, IP addresses and hosts entities can be displayed in the “Entity behavior” blade.

../2020-12-16-identity-security-monitoring/AzIdentity_AzSentinelUEBA.png Entity pages shows an “Alerts and Activities Timeline” with all incidents by “Microsoft Security products” (generated by incident creation rule) or analytic rules (built-in or custom queries) and anomalous detections based on the behavioral learning in” UEBA”. Insight box visualize anomalous activities and sign-in events from the various data sources.

Hunting Queries

Over 175 hunting queries are already integrated and can be used by “Security Analysts” to start hunting on various types of threats incl. “initial access” or “privilege escalation”. The list of hunting queries can be filtered by “data sources” and “tactics”. All queries are written in KQL and can be edited or customized. New hunting queries can be created from the blade and Microsoft is adding new “out of the box” queries on a regular basis.

Integration and Response in “Azure Sentinel”

Playbooks

A logic app can be triggered to automate “threat response” when an “analytic rule” generates the alert. All logic apps that includes “Azure Sentinel alert trigger” can be used as “Playbook”. Microsoft describes the configuration of this playbooks in one of the Azure Sentinel tutorials. As already mentioned, many logic app templates are available from GitHub. Monitoring of playbooks is an important part of daily operations (especially if it’s an essential part of your incident and response process). Workbook for “Playbook Health” might be helpful to get an overview about failed runs and latency.

In addition, there is also a “Logic App connector” for Azure Sentinel which allows to update or use information from incidents.

WatchList

Recently, Microsoft introduces Watchlist as feature to collect data from “external sources” for correlation in the analytic rules. This enables also the possibilities of enrichment by external events or business data. One of Microsoft’s playbook samples is using “WatchList” to close an incident from known IP addresses. On this general approach as an example, you can use a playbook to ingest “Trusted IP addresses from Microsoft (backend)” to enrich false-positive events of unfamiliar locations.

Notebooks

Azure Sentinel allows to use “Jupyter notebooks” running on “Azure Machine Learning” (AML) platform and using “Azure Sentinel” data. Notebook templates are already included such as an “Entity Explorer for Account” or “guided hunting on anomalous Exchange Online Sessions”.

Notebook are very powerful for hunting of security threats and allows enhancement of existing “Azure Sentinel data” by external threat intelligence.

Considerations and References of “Azure Sentinel”

You May Also Enjoy