Go back

CIEM vs. ITDR

CIEM vs. ITDR

Contents

If your organization hasn’t already adopted the Cloud, you’ll be met with one question: “Why?” The shift towards Cloud computing brings unprecedented advantages, yet it heightens exposure to cyber threats. As organizations increasingly rely on technology, unforeseen vulnerabilities often lurk in the shadows, catching security teams off guard until disaster unfolds. 

The evolution towards hybrid work models and the rising dominance of AI further complicate the landscape. 60% of mid-sized businesses that asked their employees to work remotely swiftly experienced a cyberattack. Given this dynamic scenario, a revamped strategy for countering cyber threats in Cloud environments becomes imperative.

In this article, we’ll break down two important Cloud cybersecurity approaches: CIEM and ITDR. While they address distinct aspects of cybersecurity for a Cloud environment, we will learn how they can be combined for a holistic action plan for managing security risks.

What is CIEM and How Does it Work?

Cloud Infrastructure Entitlement Management (CIEM) is primarily responsible for governing Cloud infrastructure privileges and entitlements. It manages access pathways to secure Cloud services and applications by enforcing certain principles that prevent excessive privileges and providing visibility and analytics about them. As a result, CIEM is responsible for streamlining access control, enforcing access policies, and ensuring compliance related to privileges across the entire Cloud environment.

How Does CIEM work?

To understand CIEM better, let’s break it down. Firstly, we know that a Cloud infrastructure represents the cluster of components such as servers, databases, networking hardware, and platform services representing the underlying workload for hosting an application. 

“Privileges” refers to the permissions required to access the components and data within the workloads, which are assigned to human users, connected devices, and AI bots via IAM, an essential part of any Cloud service for managing user access rules and permissions.

CIEM works in conjunction with IAM best practices. It acts as an overarching layer that audits the IAM configurations. It scans the IAM entitlement configurations to determine what permissions are allocated to humans or machines. It performs remediations, if necessary, to ensure every device or person has the right permissions.

Why Do You Need CIEM?

In today’s increasingly Cloud-centric and remote work-focused IT landscape, CIEM is crucial to administering an organization’s cybersecurity posture. CIEM solves four major problems.

1. Manual IAM Provisioning

Native IAM services supported by Cloud providers (like Azure Identity Protection) offer a manual interface that lacks intelligence about the security impact of each privilege configuration. Therefore, you’re missing out on the opportunity to use automation to act on possible blind spots. CIEM fills this gap with intelligence capabilities to automate and remediate over-privileges.

2. Misconfigured Privileges

In a complex hybrid or multi-Cloud environment, IAM provisioning leads to human privilege errors, which are difficult to visualize and understand. CIEM provides continuous visibility into all Cloud entitlements and enforces the principle of least privilege by identifying and mitigating entitlements with excessive permissions.

3. Unchecked Identity Lifecycle

How can you preempt identities in specific conditions, such as unused or dormant identities? CIEM is capable of addressing these issues through proactive identity lifecycle monitoring. It ensures that privileges are activated at the right time for the right set of identities and are quickly revoked when identities are dormant, reducing security risks.

4. Lack of Compliance

Any lapses in the above aspects of privilege management can lead to noncompliance with regulatory requirements, which creates headaches in the form of penalties or bad press. CIEM solutions help organizations meet regulatory compliance requirements by continuously monitoring and reporting access control across Cloud and multi-Cloud environments.

What is ITDR and How Does it Work?

Identity Threat Detection and Response (ITDR) tackles cybersecurity risks by safeguarding Cloud identities for accessing a Cloud infrastructure instead of infrastructure components such as servers, networking equipment, and devices.

A Cloud identity can include information like credentials and secrets and determines whether the identity can access specific resources in the Cloud environment. However, if the identity data is compromised and credentials are stolen, access gets transferred to a rogue user. ITDR helps prevent malicious use of identities like this.

ITDR maintains a vigil on each identity’s dynamic activities in the Cloud environment, including login and logout events, command execution logs on servers, and network traffic on workstations where the identity has access rights. Based on these activities, ITDR can predict possible suspicious activities arising out of any identity provisioned in the IAM.

Why Do You Need ITDR?

ITDR also adds an intelligent layer atop IAM and is essential in preserving your organization’s security posture. The significant problems addressed by ITDR include:

Static Identity Monitoring

IAM is responsible for provisioning the identities and can’t monitor how they are used in the Cloud environment. ITDR is capable of real-time monitoring of identities to ensure that all identities are used within the parameters behavior expected by the users of those identities.

Lack of Visibility in Entitlement Usage

IAM doesn’t guard the Cloud infrastructure from unruly users who want to abuse their entitlements. This rogue activity can happen knowingly or unknowingly, either by disgruntled employees or through identity theft. Based on its real-time monitoring capabilities, ITDR can flag an identity if it detects suspicious use.

Compliance gaps

ITDR looks beyond IAM’s identity and permissions configuration to investigate system logs, network traffic, and other data sources to monitor identities. Therefore, ITDR can provide deeper and more comprehensive observations on potential identity-related threats compared to IAM and CIEM.

How You Can Use CIEM and ITDR Together

CIEM and ITDR solutions provide different but complementary security capabilities over IAM. Here are a few ways to leverage these two approaches to strengthen your organization’s security posture and outsmart cybercriminals.

1. Better Visibility on Identity Lifecycle

You can leverage the capabilities of CIEM and ITDR for better visibility into the identity lifecycle. For example, CIEM can track quantitive aspects of an identity usage, whereas ITDR can deliver qualitative insights about the context in which the identity was used. 

Further, ITDR’s analysis of identity risks can establish links with cloud and IAM infrastructure where login and activity records of that identity are discovered. Therefore, by combining with CIEM, it is possible to visualize and trace the privileges, from identities all the way to cloud resources, SaaS applications, and IdPs.

2. Adaptive Security Posture

The combined strength of CIEM and ITDR is a potent weapon to dynamically equip you with the tools to respond to specific threat perceptions. 

One example is adaptive authentication. CIEM guards the authentication procedure while ITDR accesses the authentication and access related data to enforce additional policies that activate different authentication factors depending on the risks perceived by ITDR.  

3. Enhanced Threat Detection

By combining CIEM and ITDR solutions, you can enhance your threat detection and response capabilities. CIEM can help identify excessive or unused permissions that cybercriminals can exploit. At the same time, ITDR can quickly determine any matches between the credentials used in the malicious activity and those of authorized users. 

This level of scrutiny helps uncover the attack’s root cause. It provides an opportunity to bolster security measures to prevent similar incidents from occurring in the future and to reduce the blast radius of an attack.

4. Better Control of Shadow IT Practices

Shadow IT refers to using information technology systems, devices, software, applications, and services without explicit approval from your organization’s IT department. The trend of working from home has contributed to the rise of shadow IT due to the increased use of personal devices and applications. Such practices also raise concerns about security due to data inconsistency, lack of IT visibility, and compliance violations.

CIEM and ITDR can solve all the above problems associated with shadow IT practices by detecting shadow access and tracing the identities and entitlements associated with them.

5. Intelligent Policy Enforcement

IAM and CIEM often define access control policies to add additional authorization criteria to entitlements. One example is time-based access, where an entitlement is granted for a limited time. While CIEM can enforce policies like this, ITDR can bolster them to ensure the policies are in force and any unauthorized access attempts trigger alerts and responses.

6. More Efficient Workflows

Organizations can leverage CIEM and ITDR platforms to share contextual information between the two systems for better synergy in security-related workflows. It includes user identity attributes, access permissions, and historical data. This enriched data enhances the response time to security incidents.

For example, security incidents can be logged with identity-related information for better first-hand context of the affected identities and enforcing access controls as part of the incident response workflow. You can achieve similar improvements in security audit workflows.

7. Centralized Management & Monitoring of IAM

Combining CIEM and ITDR solutions provides centralized management of Cloud identities. CIEM takes care of centralized provisioning of all identities and their associated permissions and supersedes the IAM configuration to ensure minimum privileges. ITDR handles centralized monitoring of all identities and enables deep insights into identity usage and potential threats.

CIEM and ITDR: The Path to Identity Resilience in the Cloud

CIEM is a strategic initiative – it manages identity security and monitors overall identity hygiene metrics. ITDR is a tactical initiative – it detects identity gaps in real time and predicts ongoing risks arising from identity usage. 

Both approaches are relatively new in the context of cybersecurity, which was traditionally dominated by EDR and XDR-based approaches. However, CIEM and ITDR offer a more resilient way to secure Cloud infrastructure since identity theft is the most potent way to commit cyber crimes stealthily without getting noticed.  

Rezonate is an identity centric security platform that provides CIEM capabilities across the entire identity fabric (everywhere identities are operating and managed), in the IAM infrastructure (like Okta and Azure AD), and business-critical SaaS applications. Also, Rezonate’s ITDR engine uses anomaly detection and AI-driven pattern analysis to profile the level of access, drive least privileges across the board, and detect and respond to threats. To find out more, you can book a demo.

Loading

Continue Reading

More Articles
What is Azure Identity Protection and How to Get the Most out of It

What is Azure Identity Protection and How to Get the Most out of It

Azure Identity Protection is the enigmatic sentinel of the Microsoft realm. Understanding the inner workings of Azure Identity Protection is essential to any information security officer, and will unlock the keys to an effective user risk policy. Unsurprisingly, cyber attackers are sharp – they have found various ways to infiltrate and compromise digital applications. Sometimes, users make their malicious conquests even easier by using weak passwords, leaving over-privileges, and failing to recognize social engineering attacks.  So far, in 2023, 60% of medium-sized companies have reported theft of credentials. As a result, tools like Microsoft’s Azure Identity Protection have become a staple in protecting against compromised identities, account takeover, and misuse of privileges. With a strong identity protection foundation, organizations can adopt concepts like zero trust and confidently progress toward a dynamic, identity-centric model that keeps credentials safe. In this article, we will discuss what Azure Identity Protection is, its features, and its benefits. Then, we’ll review eight best practices to help you get the most out of Azure Identity Protection. What is Azure Identity Protection? Azure Identity Protection is a security service that provides a consolidated view of risky user activities and potential vulnerabilities affecting your identities. It uses adaptive machine learning algorithms to detect anomalies and suspicious incidents such as leaked credentials, sign-ins from unfamiliar locations, infected devices, and impossible travel.  The service generates reports and alerts that enable administrators to investigate and respond to possible vulnerabilities. It also provides remediation capabilities like password resets and multi-factor authentication (MFA) enforcement to resolve issues. What are the Main Features of Azure Identity Protection? Here are 5 key features of Azure Identity Protection: Risky sign-ins detection - Analyzes sign-in patterns and flags anomalous ones like logins, unfamiliar locations, infected devices, or anonymous IP addresses. Risky user detection - Identifies potentially compromised user accounts based on indicators like leaked credentials, suspicious inbox activities, and impossible travel. Risk-based conditional access policies - Automatically blocks or challenges sign-ins and users via MFA or password change. Reporting and investigation - Provides reports on risky users and sign-ins with detailed drill-downs for security teams to investigate. API access - Allows exporting risk detections to SIEMs for further correlation and automated workflows. How Can Azure Identity Protection Improve Security  Overall, Azure Identity Protection has numerous benefits for organizations, including: Detects potential vulnerabilities affecting identities. Investigates risky incidents and takes appropriate action.   Remediates issues and enforces multi-factor authentication. Identifies patterns using machine learning to enhance protection. Reduces the account takeover risk. Promptly identifies, investigates, and responds to identity threats. Helps you view and understand IAM policies.  How to Get the Most out of Azure Identity Protection  1. Engage Stakeholders Early  Securing buy-in and clarity on expectations upfront from internal stakeholders like IT security teams, infrastructure/operations teams, application owners, business leaders, etc., ensures smooth adoption and optimal use of Identity Protection, which maximizes ROI.  Tips: Identify all stakeholders impacted by Identity Protection, such as security admins, IT teams managing authentication systems, application owners, helpdesk, etc. Conduct workshops to demonstrate Identity Protection capabilities like risk modeling, automated response, and reporting. Define their roles and responsibilities in deploying, supporting, and getting value from the solution. Get their input on policies, alerts, and integrations with other tools like SIEM based on their needs. Keep them updated on timelines, changes, and requirements from their side. Set up an onboarding plan for users impacted by MFA registration and risk policies. Create a support/escalation process for issues faced by users. Establish a feedback process for continuous improvement after rollout. 2. Configure Risk Policies Azure Identity Protection allows the creation of Conditional Access policies to automatically respond to user and sign-in risks detected through its AI-driven risk modeling. Properly tuned risk policies act as automated sentinels, promptly responding to abnormal activity before incidents occur. Tips: Enable the user risk policy to enforce actions like MFA or password change for risky users. Enable the sign-in risk policy to trigger MFA prompts or block access for risky sign-in attempts. Set appropriate thresholds for user/sign-in risks based on your security posture. Aggressive thresholds lead to more false positives. Scope policies to all users or specific critical groups like administrators, based on coverage needed. Exclude emergency access accounts from the policies to prevent accidental lockout. Use report-only mode to evaluate policy impact before full enforcement. Review automated remediations in usage reports to correlate risk detections with user/sign-in actions taken. Adjust policies periodically based on analysis of risk patterns in your environment. Export risk detections to your SIEM for further correlation and monitoring coverage. Ensure sufficient testing to balance security with user experience. 3. Require MFA Registration The Azure Identity Protection policy for MFA registration prompts users to enroll for Azure AD Multi-Factor Authentication (MFA) during sign-in, strengthening account security beyond just passwords.  Tips: Enable policies for cloud services, applications, and systems, and enforce registration for all users. Gradual rollout is also an option to minimize disruption. Educate users on MFA and how it safeguards their accounts. Provide clear instructions on enrolling their devices for MFA. For mobile devices, ensure users have downloaded and activated the Microsoft Authenticator app. For desktops/laptops, guide users to enable phone-based MFA or FIDO2 security keys as the second factor. Encourage users to register multiple verification methods as backups. Prioritize MFA registration for privileged accounts like administrators to protect critical access. Consider excluding break-glass accounts from MFA to prevent a lockout. Use report-only mode initially to gauge impact before enforcing registration. Evaluate if existing MFA solutions need to be phased out after the Azure AD MFA rollout. Monitor registration status and follow up with users who don't complete registration after prompts. 4. Exclude Emergency Accounts  When configuring Azure Identity Protection risk policies for user and sign-in risks, excluding emergency access or break-glass administrator accounts from the scope is crucial. The rationale is to maintain admin access to Azure AD in worst-case scenarios like mass user lockouts due to policy misconfiguration or synchronization errors.  Tips: Create at least two emergency access accounts in your Azure AD tenant and ensure they have global administrator privileges. Explicitly exclude these accounts from the Conditional Access policies enforcing MFA, password reset, etc., for risky users/sign-ins. Have a documented process for keeping these accounts secure, including: Ensure the credentials are known only to designated people like CISOs, security leads, etc. Rotate the credentials periodically, ideally every 30-90 days. Monitor the accounts for any anomalous sign-in or usage patterns. Outline the verification process before use if accounts are accidentally locked out. 5. Add Trusted Locations Configuring named locations for office networks and VPN ranges is an essential optimization for Azure Identity Protection's risk modeling. By declaring internal networks as trusted/known locations, sign-ins originating from them will have lower risk scores in Identity Protection. This minimizes false positives and unnecessary challenges for users accessing resources on the internal corporate network. Tips: Create named locations in Azure AD Conditional Access representing office IP ranges and VPNs. Mark on-premises office networks as 'trusted locations' once configured. Configure VPN IP ranges as named locations marked as 'known.’ Update location definitions if office networks or VPNs change. Verify location mappings by checking sign-in logs to see if IP addresses are correctly matching. Exclude unnamed/unknown locations from the trusted or known designations. Review sign-in logs periodically to validate mappings. 6. Enable Security Monitoring Ongoing monitoring and alerting are critical for managing risks Azure Identity Protection detects. Robust monitoring is vital to realizing the value of Identity Protection. You can make risk visibility and response coordination a 24x7 capability through SIEM integration and smart workflows. Tips: Configure email notifications for new risky users/sign-ins and weekly digests. Alert appropriate security team members. Review Identity Protection reports like risky users, sign-ins, and risk detections daily. Create Azure Monitor dashboards to view risk trends, policy actions taken, and track remediation status. Use the Identity Protection workbook template to gain insights through interactive reports. Export Identity Protection events via the Graph Security API to your SIEM solution. Correlate risk detections with other identity-related security events in your SIEM for enhanced monitoring. Configure playbooks in solutions like Azure Sentinel to trigger response workflows based on Identity Protection alerts. Document investigation and remediation processes for security operations. 7. Train End Users An educated user base is less prone to lapses that can jeopardize account security. Continuous training and motivation help sustain user cooperation, which is crucial for successful Identity Protection usage. Tips: Inform users about new Identity Protection policies like MFA registration and risk-based sign-in challenges. Explain the needs and benefits. Provide clear instructions on enrolling for MFA during sign-in prompts.  Train users on proper password hygiene, like using strong passwords, password managers, and not reusing passwords across sites. Set up self-service password reset (SSPR) for accounts. Raise awareness about phishing attacks and how to identify suspicious emails or links. Inform users about reporting suspicious activity, like unfamiliar sign-in locations. Reward security-conscious behavior by employees to drive engagement. Track training completion rates and measure security awareness over time via red teaming. 8. Leverage Rezonate's Identity Threat Protection  While Azure Identity Protection provides fundamental risk detection capabilities, solutions like Rezonate can augment protection for cloud identities and access. Rezonate is an identity threat protection platform that integrates natively with Azure AD and continuously analyzes identity and access patterns to uncover risks. Rezonate also protects and protects and monitors potential compromises of the Azure AD admin console and infrastructure, as experienced in July this year.  Key capabilities to help you maximize Identity Protection: Discovers all human and service identities across Azure AD, Okta, Google Workspace etc., and provides a unified view. Continuously monitors privileged access and entitlements to detect anomalies and generate actionable alerts. Correlates cross-cloud identity management, events, and user behaviors to identify sophisticated attack patterns. Recommends one-click remediation actions for resolving policy violations or mitigating risks. Automates response through integration with existing workflows like Azure playbooks. Provides easy-to-understand visualizations of identity relationships and access paths to resources. Identify Vulnerabilities Before Attackers Do Azure Identity Protection offers adaptive and intelligent capabilities to identify vulnerabilities, remediate risks, and enforce access controls. You can build a comprehensive identity-centric security strategy by leveraging features like risky sign-in policies and integrating Identity Protection with solutions like Rezonate. Rezonate provides unified visibility, detection, and response powered by industry-leading identity graphs. See Rezonate in action today.
Read More
TX GROUP Case Study

TX Group: Eliminating cloud identity risk with Rezonate

Success for Switzerland’s largest international private media company means always staying ahead of the digital curve – and security is no exception. Rezonate makes this possible. “With Rezonate our DevOps and security teams are now enabled to work hand-in-hand and understand the complete identity story - across our IdP and cloud infrastructure. We reduce manual workload, increase productivity and eventually reduce the time to remediate critical risks.” Andreas Schneider, former Group CISO and Olivier Martinet, current Group CISO for TX Group The Challenge: Finding and Fixing Identity ‘Blind Spots’ – Fast Speed is of the essence in the media industry: news happens fast, and it’s imperative to deliver – and secure – it rapidly, as well.  Detecting identity issues and compromises in this complex environment, Schneider says, was like finding the proverbial “needle in a haystack.” He used several different tools to try to uncover every vulnerability, but he knew that he wasn’t seeing the complete exposure map. But finding and closing the identity and access management gaps seemed nearly impossible. AWS’s own insight tools proved difficult even for the engineers to use. So Schneider sought help – and found it in Rezonate. “We had blind spots. There were things we didn’t really think about. We check configuration, for example, but do we check privileges? If a vendor says they need access to something, it is a real challenge to continuously validate need and actual usage.”  The Solution: A team approach that really works Schneider chose Rezonate to handle TX Group’s  identity management for a number of reasons:  Real problem solving.  Rezonate sees the extent to which identities use their access privileges so TX Group can revoke  access to unused resources and applications – the “least privilege” approach.  “I don’t know of any other technology that does this. Rezonate alone could give us real-time visibility into our cloud accounts as well as guidance for quick response. We now know exactly what’s going on and where, every moment.” Rapid response. TX Group can now spot risky accounts and mitigate them with ease using Rezonate, and its security and DevOps teams can work together to resolve the identity and access issues that are so common in the cloud — without slowing or stopping operations. Rezonate accomplishes this feat via its Identity Storyline™, the brains behind the Rezonate platform. Identity Storyline simplifies complex identity and access problems and provides clear guidance on how to resolve them.Now, using Rezonate, TX Group can quickly see, in context, each identity’s behaviors in the cloud – past as well as present – and know which might increase its risk of breach, as well as how to best remediate.Identity Storyline goes beyond static dashboards to answer the dynamic questions that need always-current answers such as Where are our blind spots? Where have identities changed or deviated from patterns of behavior? Where are our active threats? “Without Rezonate, we would not be able to see these kinds of suspicious activities on all our identity providers and cloud accounts. Before, we were seeing just minor parts of our  identity and access risk. We now have the complete picture, and can make decisions with confidence.” User-readiness. The Rezonate platform software is up and running and ready to use in minutes. “Rezonate takes zero trust to the next level. Rezonate is, for me, the one-stop shop security tool for protecting our identities in the correct way – for identifying and remediating threats.” The Outcomes: A full and complete view of identities, access, and privileges via Rezonate’s Identity Storyline™ – leveling up “zero trust” security for the cloud Faster time from risk discovery to risk remediation – from days or weeks to minutes Reduced workload for DevOps and security teams as automation handles detection and remediation before risks become threats Greater productivity as DevOps works hand-in-hand with security  to safely design, create, and deploy Optimized access permissions, ensuring a “least privileges” approach Proactive, prioritized responses to risk and threats
Read More
Defending Azure Active Directory (Entra ID): Unveiling Threats through Hunting Techniques

Defending Azure Active Directory (Entra ID): Unveiling Threats through Hunting Techniques

Azure Active Directory (Entra ID) stands as one of the most popular and widely-used cloud-based identity and access management services provided by Microsoft. It serves as a comprehensive solution for managing user identities and controlling access to a diverse range of resources, both within the Microsoft Azure ecosystem and across other platforms. Azure AD offers crucial features like single sign-on (SSO), multi-factor authentication (MFA), role-based access control (RBAC), and directory services.  Understanding  Azure AD logs is essential for maintaining a robust security posture in a cloud-centric environment. These logs provide a comprehensive record of user activities, authentication attempts, and access permissions. By analyzing Azure AD logs, organizations can detect and respond to suspicious or unauthorized activities promptly, identify security threats, track user behavior, and ensure compliance with regulatory requirements. Understanding these logs is pivotal in proactively mitigating security risks, protecting sensitive data, and safeguarding the integrity of Azure-based services, making it a fundamental aspect of any effective cybersecurity strategy in the cloud. Reading this blog will provide you with: Understanding of the logs that can be extracted from your Azure AD, and how. Knowledge about how to analyze these logs, and get the right information out of them. Learning about more than 10 Threat scenarios and corresponding hunting queries that you can run in your own environment to identify threats. Access to a tool Rezonate wrote to extract logs from AzureAD to any preferred analysis platform of your choice. Azure Active Directory Log Sources Azure Active Directory (Azure AD) offers two log sources that capture different types of events and activities within the Azure AD environment. These logs provide valuable insights for monitoring, security, and compliance purposes: Sign-in Logs: capture information about user sign-ins, including successful and failed attempts, sign-in locations, device details, and authentication methods used. Directory Audit Logs: capture information about various administrative activities, such as changes to user accounts, group memberships, application access, role assignments, and permission modifications. Data retention settings for the different licensing levels can be found here. Azure AD Sign-in Logs Azure AD sign-in logs are records that capture information about user sign-in activities within the Azure Active Directory (Azure AD) environment. These logs provide insights into the authentication and access activities of users as they interact with Azure AD-integrated applications and services. Sign-in logs are a crucial component of monitoring and maintaining the security of an organization's identity and access management infrastructure. The full structure of the sign-in logs can be found on Microsoft’s official reference page. Every data-point  in the log record could be useful in certain use cases, but we highlighted some of them  that you should focus on for most investigations and hunting scenarios: IdUnique identifier for the event.CreatedDateTimeEvent time.ActivityDisplayNameThe name of the activity, used as the type of the event. The full list can be found in Microsoft’s documentation.AppId The identifier of the Azure AD application that the entity logged in to.AppDisplayNameThe name of the Azure AD application that the entity logged in toUserPrincipalNameThe user name that was used to sign in.DeviceDetailThe device information from where the sign-in occurred. This property includes the client’s operating system and browser details.IpAddressThe IP address that was used for the authentication. UserAgentThe user agent that was used for the authentication.StatusIndicates the result of the sign-in. The full list of errors can be found in Microsoft’s documentation.IsInteractiveIndicates if the sign-in was interactive or not.CorrelationIdA unique identifier that is used to correlate other logs that are related to a specific sign-in event.  Sign-in logs are separated into four groups: Interactive sign-in: Interactive sign-ins occur when a user logs in using a web browser, a mobile app, or another client application, and the user directly interacts with the authentication prompts.  Non-interactive sign-ins: These logs typically involve automated processes, such as service accounts, background tasks, or system-to-system interactions, where user intervention is not necessary for authentication to occur. Service principal sign-ins:  A service principal is a security identity used by applications, services, or automation tasks to access Azure resources and perform specific actions. Service principal sign-ins occur when these identities are used to authenticate and access resources or services. Managed identity sign-ins: A managed identity is a feature in Azure that provides an identity for resources like virtual machines, Azure services, and applications. This identity can be used to authenticate with various Azure services without requiring explicit credential management. Managed identity sign-ins occur when resources or applications use their managed identity to authenticate and access other Azure services, APIs, or resources. Azure AD Directory Audit Logs Azure AD directory audit logs are records that capture details about administrative activities and changes within an Azure Active Directory (Azure AD) environment. These logs provide insights into actions taken by administrators or privileged users that impact user identities, groups, roles, and directory settings. Directory audit logs are essential for maintaining security, compliance, and accountability within an organization's identity and access management infrastructure. These logs help track changes, monitor user activities, and investigate potential security incidents. The structure of the audit logs can be found on Microsoft’s official reference page. Each data point in this log could be useful but we highlighted some of them that you should focus on for most investigations and hunting scenarios: IdUnique identifier for the event.ActivityDateTimeEvent time.ActivityDisplayNameThe name of the activity is used as the type of the event. The full list can be found in Microsoft’s documentation.InitiatedBy Provides information about the entity that performed the action that triggered the event.TargetResourcesThe resources that were involved in the event.ResultIndicates the result of the eventResultReasonLogs the reason for a failure if the event was not successful.CorrelationIdA unique identifier that is used to correlate the event to a specific sign-in event.  Exporting Azure AD Logs Exporting  Azure AD  logs requires one of the following roles: Reports Reader Security Reader Security Administrator Global Reader Global Administrator There are two primary approaches to accessing Azure AD logs. 1. Azure AD Console: In the monitoring section, you will find both “Sign-in Logs” and “Audit logs”. Login to Azure Portal From the Azure Services, select Azure Active Directory From the left pane, navigate to the “Monitoring” section Each sign-in event, of an interactive user, is displayed as a single event and can be expanded to view more detailed information: The tree remaining sign-in log groups are displayed differently. Instead of showing each sign-in attempt in a single event, the sign-in events are grouped by the target application that the user signed into: 2. Exporting The Logs To CSV\JSON While accessing the Azure AD logs from the Azure portal is easy, it is recommended to export the logs out of  Azure AD  so you will be able to cross reference Azure AD activity with other data sources and perform advanced queries and analyze it in scale. To export logs from Azure AD, we recommend using an Azure AD application and Microsoft Graph API. Follow the instructions below to create a new application for logs export in your tenant: Sign in to the Azure portal using your administrator account. From the Azure services, choose Azure Active Directory. From the left pane, choose App Registrations Click on “New Registration”. Name it as you wish. In “Supported account types” select  “Accounts in this organizational directory only (Default Directory only - Single tenant)”. Click Register. In the newly created application page, from the left pane, choose API Permissions. Click on Add permission. Click on Microsoft Graph - Application Permissions. Type “AuditLog” in the search box. Click on “AuditLog.Read.All”, and then “Add permissions”. Grant admin consent for the default directory - In other words, allow the application to use the assigned privileges. From the left pane, choose “Certificates and Secrets” Click on “New client secret” Choose your desired expiration date. Use the new secret to authenticate to Azure AD and query your logs. Let the Hunt Begin In this section, we will guide you through some of the top-relevant threat scenarios to look out for, explain them, mark the Relevant Azure AD Event Sources, align to the specific MITRE ATT&CK technique, and include our own queries in Postgres query syntax. Scenario 1 - Brute Force on an Azure AD User A brute force attack on an Azure AD user involves an attacker repeatedly trying different passwords to guess correctly and eventually gaining unauthorized access. To hunt for any occurrence of this scenario, you can search for an actor that performed more than X failed login attempts on at least Y target user, failing or ending up with a successful login. In cases of failure, the activity may result in a user's lockage. (Read more about Microsoft’s Smart Lockout protection mechanism) Relevant Azure AD Event Source Azure AD Sign-In Logs Query -- Get users who failed to login from the same IP address at least 5 times SELECT "userPrincipalName", "ipAddress" , "appDisplayName", "userAgent", count(id) as "eventCount", min("createdDateTime") as "first_event", min("createdDateTime") as "last_event" FROM sign_in_activity_azure_ad_entity siaaae WHERE "errorCode" = 50126 -- Error code for invalid credentials AND "createdDateTime" > now() - interval 'X hours' GROUP BY "userPrincipalName", "ipAddress", "appDisplayName", "userAgent" having count(id) >= 5 ORDER BY "eventCount" desc MITRE Technique Credential Access | Brute Force | ATT&CK T1110  Attention: The user-agent field in authentication logs indicates the client application employed for the authentication process. To bypass modern authentication requirements like Multi-Factor Authentication (MFA), threat actors might exploit legacy authentication protocols such as SMTP. In cases where a legacy protocol is utilized for authentication, the user agent in the logs will be identified as 'BAV2ROPC'. In case you encounter a brute force attempt with the user agent set to 'BAV2ROPC', it is crucial to consider it as malicious unless proven otherwise. Scenario 2 - Password Spray on an Azure AD Account A password spray attack on an Azure AD account involves an attacker repeatedly submitting different usernames with the same password (a small set of passwords) to eventually manage to log in and gain unauthorized access. To hunt for any occurrence of this scenario, you can search for an actor that performed more than 1 failed login attempt on at least Y unique target user, from the same IP address. Relevant Azure AD Event Source Azure AD Sign-In Logs Query -- Get users who failed to login from the same IP address to at least 5 unique users SELECT "ipAddress", "appDisplayName", "userAgent", count(distinct "userPrincipalName") as "eventCount", min("createdDateTime") as "first_event", min("createdDateTime") as "last_event" FROM sign_in_activity_azure_ad_entity siaaae WHERE "errorCode" = 50126 -- Error code for invalid credentials AND "createdDateTime" > now() - interval '1000 hours' GROUP BY "ipAddress", "appDisplayName", "userAgent" having count(id) >= 5 ORDER BY "eventCount" desc -- For Each result, check if the source IP address managed to login to the target user AFTER the "lastEvent" time MITRE Technique Credential Access | Brute Force | ATT&CK T1110 Scenario 3 - Multiple User Lockouts In certain instances of brute force attacks, the malicious actor may lock out the targeted users during their unauthorized access attempts. To identify such scenarios, we can employ a detection method that involves searching for multiple user lockouts originating from a single IP address. Relevant Azure AD Event Source Azure AD Sign-In Logs Query -- Search for login attempts to disabled users SELECT "ipAddress", count(distinct "userPrincipalName") AS "userCount", "appDisplayName", "userAgent", min("createdDateTime") as "first_event", min("createdDateTime") as "last_event" FROM sign_in_activity_azure_ad_entity WHERE "errorCode" = 50053 -- Error code for user locked out AND "createdDateTime" > now() - interval 'X hours' GROUP BY "ipAddress", "appDisplayName", "userAgent" having count(distinct "userPrincipalName") >= 5 ORDER BY "userCount" desc MITRE Technique Credential Access | Brute Force | ATT&CK T1110  Scenario 4 - Multiple Authentication Failures During MFA Challenge An attacker that managed to compromise a credential set of an AzureAD user that is protected by MFA, upon authentication, will generate a specific sign-in log with the error code 500121 which correlates with the following message: “The user didn't complete the MFA prompt. They may have decided not to authenticate, timed out while doing other work, or have an issue with their authentication setup.” We can highlight suspicious IP addresses that generated multiple events with the mentioned error code.  Relevant Azure AD Event Source Azure AD Sign-In Logs Query -- Search for failed authentication attempts during MFA challenges SELECT "userPrincipalName", "ipAddress", "appDisplayName", "userAgent", count(id) as "eventCount", min("createdDateTime") as "first_event", min("createdDateTime") as "last_event" FROM sign_in_activity_azure_ad_entity siaaae WHERE "errorCode" in 500121 -- Error code for no MFA response AND "createdDateTime" > now() - interval '2000 hours' GROUP BY "userPrincipalName", "ipAddress", "appDisplayName", "userAgent" having count(id) > 1 ORDER BY "eventCount" desc MITRE Technique Credential Access | Brute Force | ATT&CK T1110  Scenario 5 - Authentication Attempt to a Disabled User  In some cases, Azure AD user accounts might have been disabled due to security concerns, or maybe even as part of employee off-boarding. Monitoring login attempts to disabled users can help you detect unauthorized activities. Relevant Azure AD Event Source Azure AD Sign-In Logs Query -- Search for login attempts to disabled users SELECT "ipAddress", count(distinct "userPrincipalName") AS "userCount", "appDisplayName", "userAgent", min("createdDateTime") as "first_event", min("createdDateTime") as "last_event" FROM sign_in_activity_azure_ad_entity WHERE "errorCode" = 50057 -- Error code for user disabled --AND "createdDateTime" > now() - interval 'X hours' - optional filter GROUP BY "ipAddress", "appDisplayName", "userAgent" ORDER BY "userCount" desc MITRE Technique Credential Access | Brute Force | ATT&CK T1110  Scenario 6 - Suspicious User Consent to Application When an attacker gains access to an Azure AD Tenant, they can create a new multi-tenant application equipped with specific API permissions such as Mail.Read, Mail.Send, Mailboxsettings.ReadWrite, Files.ReadWrite.All and User.ReadBasic.All, of which do not require administrative consent. Next, the attacker invites external users (potential victims) to use this application. Upon the first login by a new user to the attacker's application, a "Consent" prompt appears. If the user grants consent to the application, it enables the application to perform actions on behalf of the user, potentially leading to unauthorized access and misuse of the user's data and resources. We can utilize non-administrative consents to detect privileged applications that have access to user data. Relevant Azure AD Event Source Azure AD Directory Audit Logs Query -- Search for non-administrative application consent select id,dn,"newValue" from (select id, jsonb_array_elements(jsonb_array_elements("targetResources")->'modifiedProperties')->>'displayName' as "dn", jsonb_array_elements(jsonb_array_elements("targetResources")->'modifiedProperties')->>'newValue' as "newValue" from directory_audit_activity_azure_ad_entity daaaae where "activityDisplayName"='Consent to application') as subsearch where dn='ConsentContext.IsAdminConsent' and "newValue"='"False"' MITRE Technique Initial Access | User Consent | ATT&CK T1204  Scenario 7 - Persistence Via Service Principal Credentials An attacker could establish a persistence mechanism by adding new credentials to an already existing Azure AD application if one of the following applies to them: Application Administrator  Global Administrator (GA)  microsoft.directory/applications/credentials/update Relevant Azure AD Event Source Azure AD Directory Audit Logs Query -- Search new application credentials events SELECT "id","user","ip", "activityDateTime", "activityDisplayName", "property", count("oldVals") AS "oldValsCount", count("newVals") AS "newValsCount" FROM ( SELECT "id","user","ip", "activityDateTime", "activityDisplayName", "property", jsonb_array_elements("oldVal"::jsonb) AS "oldVals",jsonb_array_elements("newVal"::jsonb) AS "newVals" FROM ( SELECT "id", "initiatedBy"->'user'->>'ipAddress' AS "ip", "initiatedBy"->'user'->>'userPrincipalName' AS "user", "activityDateTime", "activityDisplayName", jsonb_array_elements(jsonb_array_elements("targetResources")->'modifiedProperties')->>'displayName' AS "property", jsonb_array_elements(jsonb_array_elements("targetResources")->'modifiedProperties')->>'oldValue' AS "oldVal", jsonb_array_elements(jsonb_array_elements("targetResources")->'modifiedProperties')->>'newValue' AS "newVal" FROM directory_audit_activity_azure_ad_entity WHERE "activityDisplayName" = 'Update application – Certificates AND secrets management ' ) AS subquery WHERE "oldVal"!='[]' and "oldVal" is not null) AS query GROUP BY "id","user","ip", "activityDateTime", "activityDisplayName", "property" HAVING count("newVals")> count("oldVals") MITRE Technique Persistence | Additional Credentials | ATT&CK T1098 Scenario 8 - Admin Privileges Assignments Not Via PIM Azure AD PIM (Azure Active Directory Privileged Identity Management) is a Microsoft Azure service that helps organizations manage, control, and monitor access to privileged roles and resources in their Azure environment. It allows administrators to grant just-in-time privileged access, enforce approval workflows, and provide auditing and reporting for enhanced security and compliance.It is important to monitor Azure AD admin privileges assignments, not through PIM, since this behavior should not be common, and might suggest that an admin account is compromised. Relevant Azure AD Event Source  Azure AD Directory Audit Logs Query -- Search AAD administrative privileges assignment not via PIM select "ipAddress", "initiatedUser",category,"operationType", "targetResourceType", coalesce("targetUser","targetApp") as "targetDisplayName", ass3."value" as "newRoleName" from (select "id","ipAddress","userPrincipalName" as "initiatedUser",category,"operationType","TR"->'type' as "targetResourceType", nullif("TR"->'userPrincipalName', 'null') as "targetUser", nullif("TR"->'displayName', 'null') as "targetApp" from directory_audit_activity_azure_ad_entity daaaae , jsonb_array_elements("targetResources") as "TR" where category='RoleManagement' and "operationType" ='Assign' and "targetResources"::text like '%dmin%' and ("initiatedBy"->'app'->>'displayName' != 'MS-PIM' or "initiatedBy"->'user' is not null)) bq, (select * from (select "id",jsonb_array_elements("sub")->>'newValue' as "value", jsonb_array_elements("sub")->>'displayName' as "valueName" from (select "id",jsonb_array_elements("targetResources")->'modifiedProperties' as "sub" from directory_audit_activity_azure_ad_entity where category='RoleManagement' and "operationType" ='Assign') base1) base2 where "valueName" = 'Role.DisplayName') as base3 where bq."id" = ass3."id" and "targetResourceType"!='"Role"' MITRE Technique Privilege Escalation | Privilege Assignment via Valid Account | ATT&CK T1078 Scenario 9 - Account Hijacking Social engineering for initial access is on the rise. These techniques are simple in most cases and do not require much technical knowledge. Attacks such as phishing, MFA relay, or even buying credentials online may help attackers compromise user accounts.Usually, when an adversary compromises a user, gaining persistent access to that account is important. To do so, the adversary might change the user’s password and enroll a new MFA device. In some cases maybe even delete the original user’s factors.The following query identifies user accounts that performed a series of actions from an IP address that is not being used often by the organization, and during a short period of time - which might suggest that these accounts are compromised. The actions that this query searches for are: Self-password reset MFA enrollment MFA deletion  Relevant Azure AD Event Source  Azure AD Directory Audit Logs Azure AD Sign-In Logs Query -- Search multiple security information changes from a rare location in a short timeframe select * from(with org_ips as (SELECT count("timebucket"), "ipAddress","countryOrRegion" FROM ( SELECT DATE_TRUNC('day', "createdDateTime") AS TimeBucket, COUNT(distinct "userPrincipalName") AS "userCount", "ipAddress","countryOrRegion" FROM sign_in_activity_azure_ad_entity WHERE "errorCode" = 0 AND "createdDateTime" > now() -interval '1 week' GROUP BY TimeBucket, "ipAddress", "countryOrRegion" HAVING COUNT(distinct "userPrincipalName") > 1 ) subquery GROUP BY "ipAddress","countryOrRegion" HAVING count("timebucket") > 1) select count(distinct "activityDisplayName") as distinct_event_count, min("activityDateTime") as first_event, max("activityDateTime") as last_event, daaaae."ipAddress", "userPrincipalName",array_agg(distinct "activityDisplayName") as events, "result", age(max("activityDateTime"),min("activityDateTime")) as duration, extract(EPOCH FROM max("activityDateTime")) - extract(epoch from min("activityDateTime")) as duration_epoch from directory_audit_activity_azure_ad_entity daaaae , org_ips where "activityDisplayName" in ('Reset password (self-service)', 'Self-service password reset flow activity progress', 'User deleted security info', 'User registered security info', 'User started security info registration') and daaaae."ipAddress" not in (select distinct org_ips."ipAddress" from org_ips) and "result"='success' group by "userPrincipalName",daaaae."ipAddress", "result") base where distinct_event_count = 5 and duration_epoch <= 604800 MITRE Technique Initial Access | Social Engineering and Phishing | ATT&CK T1566 Scenario 10 - Abusing Third-Party Users (Supply Chain Attack) Many Azure AD tenants are trusted by third-party accounts - IT providers, security tools, or maybe trusted partners. Third-party accounts should perform directory changes only if the activity is authorized by the tenant administrator. Use the following query to detect changes performed by guest accounts in your organization. Unauthorized activities may suggest that the third-party account is compromised  Relevant Azure AD Event Source Azure AD Directory Audit Logs Query -- Guest directory changes select daaaae."activityDateTime", daaaae."ipAddress", daaaae."userPrincipalName", daaaae."activityDisplayName", daaaae."result", jsonb_array_elements(daaaae."targetResources")->>'userPrincipalName' as "external_user_name", siaaae."homeTenantId", siaaae."resourceTenantId" from directory_audit_activity_azure_ad_entity daaaae, sign_in_activity_azure_ad_entity siaaae where "result" ='success' and daaaae."correlationId" = siaaae."correlationId" and siaaae."homeTenantId" is not null and siaaae."homeTenantId"!=siaaae."resourceTenantId" MITRE Technique Execution | Trust Relationships | ATT&CK T1566 Scenario 11 - Abusing Single Password Authentication Single-factor authentication is a security risk that is best avoided by enforcing MFA, but it is not always possible to do so. Adversaries will often try to abuse users that are not protected by MFA. Use the following query to monitor single-factor authentication from non-organizational IP addresses. Relevant Azure AD Event Source Azure AD Directory Audit Logs Query -- Guest invites with org_ips as (SELECT count("timebucket"), "ipAddress","countryOrRegion" FROM ( SELECT DATE_TRUNC('day', "createdDateTime") AS TimeBucket, COUNT(distinct "userPrincipalName") AS "userCount", "ipAddress","countryOrRegion" FROM sign_in_activity_azure_ad_entity WHERE "errorCode" = 0 AND "createdDateTime" > now() -interval '1 week' GROUP BY TimeBucket, "ipAddress", "countryOrRegion" HAVING COUNT(distinct "userPrincipalName") > 1 ) subquery GROUP BY "ipAddress","countryOrRegion" HAVING count("timebucket") > 1) select "createdDateTime", "ipAddress", "autonomousSystemNumber", "countryOrRegion", "userPrincipalName" , "appDisplayName", "conditionalAccessStatus" from sign_in_activity_azure_ad_entity siaaae where "authenticationRequirement" ='singleFactorAuthentication' and "errorCode" = 0 and "isInteractive" = true and "ipAddress" not in (select distinct "ipAddress" from org_ips) and "countryOrRegion" not in (select distinct "countryOrRegion" from org_ips) MITRE Technique Initial Access | Valid Cloud Account | ATT&CK T1078.004 Scenario 12 - Azure AD Sync Abuse Azure AD Connect is a Microsoft tool that enables synchronization and integration between on-premises Active Directory (AD) and Azure Active Directory (Azure AD). It allows organizations to extend their on-premises identity infrastructure to the cloud, providing users with a seamless single sign-on experience across both environments.  AAD Connect synchronizes user accounts between on-premises domain controllers and AAD tenants, utilizing a privileged user account authorized to update to the AAD directory. A compromised domain controller could allow an attacker to move laterally to Azure AD by extracting the login credentials of an AAD Connect user.  Relevant Azure AD Event Source  Azure AD Directory Sign-In Logs Query -- Search AAD Connect user abuse select "createdDateTime", "ipAddress", "countryOrRegion", "userPrincipalName", "appId","appDisplayName", "errorCode" from sign_in_activity_azure_ad_entity siaaae where "userPrincipalName" ilike 'Sync_%' and "appDisplayName" not in ('Microsoft Azure Active Directory Connect','') MITRE Technique Initial Access | Valid Cloud Account | ATT&CK T1078.004 3 Additional Queries For Azure AD Access Governance On top of the scenarios mentioned above, there are additional relevant queries that can be used to hunt for threats in an Azure AD tenant. Their results are harder to rely on since they require having a deeper context of the regular activities in the organization to differentiate the legitimate operations from those that may be part of an actual threat. For example, a user was assigned an administrative role. It could be malicious or legitimate, and requires triage for a verdict:  Who performed the action? Is this the first time this actor assigns privileges?  Are there any client characteristics that do not make sense coming from that actor? Query 1 - New Application Creation Malicious applications can serve adversaries to get their first foothold in an Azure AD tenant. Review the installed applications that were installed by administrators. Relevant Azure AD Event Source Azure AD Directory Audit Logs Query -- Search for new AAD applications select "activityDateTime", "ipAddress", "userPrincipalName", "activityDisplayName", "result", jsonb_array_elements("targetResources")->>'displayName' as "appName" from directory_audit_activity_azure_ad_entity daaaae where "activityDisplayName" ='Add application' MITRE Technique https://attack.mitre.org/techniques/T1204/ Query 2 - A Guest Was Invited to the Organization Guest users can be invited to an Azure AD tenant - This means that users from different Azure AD tenants can access your tenant. It’s important to review these invites to make sure that only authorized third-party users will be invited. Relevant Azure AD Event Source Azure AD Directory Audit Logs Query -- Guest invites select "activityDateTime", "ipAddress", "userPrincipalName", "activityDisplayName", "result", jsonb_array_elements("targetResources")->>'userPrincipalName' as "external_user_name" from directory_audit_activity_azure_ad_entity daaaae where "activityDisplayName" ='Invite external user' MITRE Technique https://attack.mitre.org/techniques/T1199/ Query 3 - New Authentication Policy Exclusion Azure AD Conditional Access Policy is a powerful feature that controls access to the organization based on specific criteria. If a user or a group of users are excluded from a conditional policy, they might put the organization at risk. Relevant Azure AD Event Source Azure AD Directory Audit Logs Query -- Policy Exclusions select "activityDateTime", "userPrincipalName", category, "activityDisplayName", "operationType",jsonb_array_elements("targetResources")->>'displayName' as "policyName", jsonb_array_elements(jsonb_array_elements("targetResources")->'modifiedProperties')->>'newValue' as "newConditions", jsonb_array_elements(jsonb_array_elements("targetResources")->'modifiedProperties')->>'oldValue' as "oldConditions" from directory_audit_activity_azure_ad_entity daaaae where "activityDisplayName"='Update conditional access policy' MITRE Technique https://attack.mitre.org/techniques/T1556/ Rezonate Tool For Exporting Azure AD Logs As promised, we have included 2 tools that can be used to accelerate the application creation and the log extraction process. They are both available in our GitHub repository.
Read More
See Rezonate in Action

Eliminate Attacker’s Opportunity To Breach Your Cloud today

Organizations worldwide use Rezonate to protect their most precious assets. Contact us now, and join them.