← Back to list

Developing and Benchmarking Custom KQL Rules for

Detecting Post-Compromise Active Directory Evasion in Cloud-Hybrid Frameworks

Shahzaib Sajid · 2026-07-10 04:43 · 0 claps · 17.2 min read
#detection-engineering #active-directory #hybrid-cloud #post-compormise #soc
Open on Medium ↗
Wiki topics: EVAL · Evaluation & Benchmarks 🔒 · Cybersecurity 🎬 · Film & Television

Developing and Benchmarking Custom KQL Rules for

Detecting Post-Compromise Active Directory Evasion in Cloud-Hybrid Frameworks

Abstract

The integration of on-premises Active Directory and cloud identification systems like Microsoft Entra ID have revealed fresh attack techniques enabling hackers to move side-by-side across hybrid environments free from standard detecting tools. In this study five original Kusto Query Language (KQL) detection rules meant to spot Active Directory evasion techniques following a compromise — including Seamless SSO key change, abuse of Exchange hybrid certificates, and reconnaissance enhanced by artificial intelligence — are developed and evaluated. These rules were developed for syslog data gathered from an Ubuntu virtual machine running in a VMware lab environment using Azure Sentinel. Along with detection rates ranging from 85% to 94%, validation results indicate false positive rates of 2% to 5%. This paper discusses a systematic approach to detection engineering, offers helpful open-source KQL recommendations for security operations teams, and addresses designing AI-focused benchmarking tools as CTI-REALM. The findings emphasize how critical behavior-driven detection is in hybrid cloud settings above signaturefocused techniques.

Active Directory, KQL, Detection Engineering, Hybrid Cloud, Microsoft Entra ID, Azure

Sentinel, MITRE ATT&CK, Cybersecurity

Ethical Considerations

This research was conducted entirely within a controlled laboratory setting using a local VMware virtual machine along with a free trial of Azure Sentinel. The investigation did not reveal any real user stories, production information, or genuine organizational tools. Independent tests conducted with explicit permission executed all of the attack simulations, which included modifications to Kerberos tickets, testing of LDAP replication, and adjustments to privilege groups. The KQL rules developed in this research serve only to assist security operations teams in recognizing harmful behavior for the purpose of defense. No unauthorized methods or tools were utilized against any system. The findings and detection rules are sensibly shared to contribute to an improved cybersecurity stance, and are not intended to facilitate or endorse malicious activities.

1 Introduction

1.1 The Evolving Threat Landscape

Active Directory still serves as basic pillar of enterprise identity infrastructure, which is prime source of authentication and authorization for most of the organizations. On the contrary, the traditional security which is the boundary between on-premises Active Directory and cloud identity services is becoming increasingly prone to attacks since organizations are adopting hybrid cloud infrastructures.

Recently, a research presented in Black Hat USA 2025 showed that multiple techniques can be used to bypass authentication in hybrid Active Directory and Entra ID environments. Security researcher Dirk-jan Mollema showed how cloud accounts with low privileges can be escalated to become hybrid admins which can grant extensive permissions without triggering any alert [1, 2, 3]. These techniques can be used to exploit the trust relationships existing in the hybrid configurations, which can be used by attackers to impersonate any type of synced hybrid user including those users with high level permissions, while also bypassing traditional detection rules [4, 5, 6].

1.2 The Detection Challenge

There are certain challenges in hybrid environments in behaviors after compromise:

Lack of visibility: Many hybrid attacks like seamless SSO key manipulation, not sending enough audit logs during exploitation, due to which many generic monitoring systems can’t really detect them. Creating a backdoor in authentication protocols can also be done without triggering any security alarm which can grant persistence in the host after bypassing MFA.

Evasion strategies: Attackers these days are using AI tools to get information on certain topics of Active Directory and to assess endpoint defenses quickly which can cross the capabilities of static detection rules. Traditional signatures which were designed against human-paced attacks are also failing against automated reconnaissance and evasion tactics.

Complexity of Integration: Hybrid environment creates complex trust boundaries where on-premises and cloud-based threats are hard to correlate. Attackers can leverage exchange hybrid certificates to create service-to-service token with global administrator access without any visibility.

1.3 Research Objectives

This paper aims to:

  1. Identifying critical post-compromise Active Directory evasion techniques in hybrid environments

  2. Developing KQL detection rules that can deal with visibility gaps

  3. Establishing a technique for enhancing detection effectiveness

  4. Exploring emerging techniques for automated detection engineering

2 Understanding the Hybrid Active Directory Attack Surface

2.1 Critical Attack Vectors

Recent research has identified several attack vectors that exploit hybrid configurations:

Seamless SSO Key Manipulation: Adversaries with on-premises Active Directory permissions can input custom made symmetric keys into OnPremAuthenticationFlowPolicy which enables RC4-encrypted Kerberos to generate tickets for any domain user. This technique uses the trustedfordelegation claim in JWT tokens which can allow impersonation of any hybrid user account without even triggering any audit logs.

Exchange Hybrid Certificate Abuse: Adversaries can get exchange hybrid certificates from on-premises servers and use them to request service-to-service token which can provide them access to Exchange online and SharePoint without any restrictions, continue to work without any conditional access policy. This cannot be revoked once it is issued

[7].

Low-Privilege Cloud Account Escalation: A cloud account with least privileges can be converted to hybrid user which can grant them admin rights. This technique can bypass API controls as well under certain conditions without triggering any detection mechanism.

2.2 The MITRE ATT&CK Alignment

These attack techniques map to several MITRE ATT&CK tactics, primarily: • Defense Evasion (TA0005): Techniques that can modify authentication policies in order to bypass MFA

• Credential Access (TA0006): Forging Kerberos tickets and extracting hybrid certificates

• Lateral Movement (TA0008): Moving between on-premises and cloud environments

Many open-source KQL rules do not correctly correspond to MITRE ATT&CK since their mapping accuracy is barely 40% [10, 11]. This emphasizes the need of a systematic method in regulation design and review.

3 Methodology

3.1 Research Approach

This research follows a systematic detection engineering methodology to develop and benchmark KQL rules for identifying post-compromise Active Directory evasion techniques in hybrid environments. The methodology consists of four phases:

3.2 Phase 1: Threat Modeling

The first phase involved identifying critical attack vectors that exploit hybrid configurations based on recent research presented at Black Hat USA 2025 and analysis of real-world attack patterns. Key techniques including Seamless SSO key manipulation, Exchange hybrid certificate abuse, and low-privilege cloud account escalation were prioritized based on their ability to bypass traditional detection controls.

3.3 Phase 2: Telemetry Analysis

The second phase analyzed available telemetry sources within Microsoft hybrid environments, including Microsoft Defender for Identity, Azure AD Identity Protection, and Microsoft Sentinel. This analysis identified the specific log events and data fields that could indicate malicious activity, with particular attention to techniques that generate minimal audit logs.

3.4 Phase 3: KQL Rule Development

The third phase involved developing KQL detection rules using the identified telemetry sources. Rules were designed to detect behavioral patterns rather than relying on known signatures, incorporating threshold-based detection, velocity analysis, and contextual anomaly identification [12]. Each rule was crafted based on specific attack patterns and tested against known benign activity to reduce false positives.

3.5 Phase 4: Rule Validation

The fourth phase validated the developed rules against known attack telemetry and simulated attack scenarios. Rules were evaluated based on detection accuracy, false positive rates, and operational performance. The validation process followed benchmarking approaches similar to CTI-REALM, assessing both standalone rule effectiveness and integration into detection workflows [8].

4 Developing KQL Detection Rules

4.1 Plan for Detection Engineering

One must use a methodical method to correctly create hybrid AD evasion detection:

Knowing the methods and telemetry indicators adversaries utilize will help us to direct threat modeling. For example, managing Seamless SSO keys needs caution against unapproved modifications in authentication methods even without audit logs.

Method correspondence with already available data sources Significant Tools including Microsoft Defender for Identity, Azure AD Identity Protection, and Microsoft Sentinel inside hybrid systems assist to provide telemetry.

Developing KQL searches that spot patterns in behavior instead of depending only on known signatures. This examines thresholding, speed analysis, and background anomaly identification [12].

4.2 Rules for KQL Detection

The following KQL rules are completely essential to spot AD avoidance after compromise based on actual attack tactics and detection needs study [13]:

4.2.1 Rule 1: Detecting Suspicious Authentication Policy Modifications

This query helps identify suspicious policy modifications that can indicate backdoor key injection on Linux systems.

Syslog
| where TimeGenerated > ago(30d)
| where Facility in ("auth", "authpriv")
| where SyslogMessage contains "PAM" or SyslogMessage contains "authentication policy" or SyslogMessage contains "password policy" or SyslogMessage contains "SSH authentication policy" or SyslogMessage contains "sudoers" or SyslogMessage contains "Kerberos delegation" or SyslogMessage contains "account lockout" or SyslogMessage contains "session timeout" or SyslogMessage contains "PermitRootLogin"
| project TimeGenerated, HostName, Facility, LogLevel, SyslogMessage
| order by TimeGenerated desc

Listing 1: Rule 1: Authentication Policy Modifications

Figure 1: Rule 1: Suspicious Authentication Policy Modifications — Detection Results

Figure 1: Rule 1: Suspicious Authentication Policy Modifications — Detection Results

4.2.2 Rule 2: Hunting Seamless SSO Abuse

This query identifies Seamless SSO usage from unexpected sources, potentially indicating forged ticket abuse.

Syslog
| where TimeGenerated > ago(30d)
| where Facility in ("auth", "authpriv", "daemon")
| where SyslogMessage contains "krb5kdc" or SyslogMessage contains "kerberos" or SyslogMessage contains "TGT" or SyslogMessage contains "KDC" or SyslogMessage contains "AZUREADSSOACC" or SyslogMessage contains "AS-REQ" or SyslogMessage contains "GSSAPI" or SyslogMessage contains "kadmin" or SyslogMessage contains "sssd"
or (SyslogMessage contains "kerberos" and SyslogMessage contains "
ticket")
or (SyslogMessage contains "pre-authentication" and SyslogMessage
contains "kerberos")
| project TimeGenerated, HostName, Facility, LogLevel, SyslogMessage
| order by TimeGenerated desc

Listing 2: Rule 2: Seamless SSO Abuse

Figure 2: Rule 2: Seamless SSO Abuse — Detection Results

Figure 2: Rule 2: Seamless SSO Abuse — Detection Results

4.2.3 Rule 3: Detecting DCShadow/DCSync Activity

This query identifies potential DCSync attacks, which are often used for credential theft and lateral movement.

Syslog
| where TimeGenerated > ago(90d)
| where Facility in ("daemon", "local4", "local5")
| where SyslogMessage contains "slapd" or SyslogMessage contains "openldap" or SyslogMessage contains "LDAP replica" or SyslogMessage contains "directory replication" or SyslogMessage contains "Replicating Directory" or SyslogMessage contains "ldapsearch" or SyslogMessage contains "ldapmodify" or SyslogMessage contains "replication" or SyslogMessage contains "sync update" or SyslogMessage contains "1131f6ad" or SyslogMessage contains "89e95b76" or SyslogMessage contains "replica sync"
| project TimeGenerated, HostName, Facility, LogLevel, SyslogMessage
| order by TimeGenerated desc

Listing 3: Rule 3: DCShadow/DCSync Activity

Figure 3: Rule 3: DCShadow/DCSync Activity — Detection Results

Figure 3: Rule 3: DCShadow/DCSync Activity — Detection Results

4.2.4 Rule 4: Monitoring Privileged Group Membership Changes

This query detects unauthorized additions to privileged groups, a common post-compromise activity.

let Groups = dynamic(['sudo', 'root', 'wheel', 'adm', 'sys', 'admin', ' operator', 'docker']); Syslog
| where TimeGenerated > ago(48h)
| where Facility in ("auth", "authpriv", "user")
| where SyslogMessage contains "usermod" or SyslogMessage contains "groupadd" or SyslogMessage contains "gpasswd" or SyslogMessage contains "useradd" or SyslogMessage contains "sudoers" or SyslogMessage contains "groupmod" or SyslogMessage contains "shadow" or SyslogMessage contains "added to group"
| extend Group = extract("(sudo|root|wheel|adm|sys|admin|operator| docker)", 0, SyslogMessage)
| where Group in (Groups)
| project TimeGenerated, HostName, Facility, LogLevel, SyslogMessage, Group
| order by TimeGenerated desc

Listing 4: Rule 4: Privileged Group Membership Changes

Figure 4: Rule 4: Privileged Group Membership Changes — Detection Results

Figure 4: Rule 4: Privileged Group Membership Changes — Detection Results

Figure 5: Rule 4: Privileged Group Changes — Detection Alert

Figure 5: Rule 4: Privileged Group Changes — Detection Alert

4.2.5 Rule 5: Detecting AI-Assisted Reconnaissance

This query detects automated reconnaissance patterns characteristic of AI-assisted attacks using velocity-based detection.

let threshold = 30; Syslog
| where TimeGenerated > ago(1h)
| where Facility in ("daemon", "local4")
| where SyslogMessage contains "ldapsearch" or SyslogMessage contains "ldapquery" or SyslogMessage contains "slapd" or SyslogMessage contains "LDAP query" or SyslogMessage contains "ldap_modify" or SyslogMessage contains "Replicating Directory" or SyslogMessage contains "directory replication"
| summarize QueryCount = count() by HostName, bin(TimeGenerated, 1m)
| where QueryCount > threshold
| order by QueryCount desc

Listing 5: Rule 5: AI-Assisted Reconnaissance

Figure 6: Rule 5: AI-Assisted Reconnaissance — Detection Results

Figure 6: Rule 5: AI-Assisted Reconnaissance — Detection Results

Figure 7: Rule 5: AI-Assisted Reconnaissance — Detection alert

Figure 7: Rule 5: AI-Assisted Reconnaissance — Detection alert

Figure 8: Rule 5: AI-Assisted Reconnaissance — LDAP Query Results

Figure 8: Rule 5: AI-Assisted Reconnaissance — LDAP Query Results

4.3 Rule Tuning and Optimization

Effective KQL guidelines must be carefully adjusted to achieve a harmony between operational efficiency and precision in detection:

Employing appropriate time frames such as 30 days or 90 days according to the nature of the threat and requirements for data storage.

Creating a standard: Recognizing standard behaviors will aid in reducing false alarms. Define company-specific benchmarks for velocity-focused detections rather than relying on static limits.

Exclusion Filtering: Implementing logical exclusions for legitimate administrative operations (for instance, omitting known domain controller accounts from DCSync detection queries) is essential.

5 Results and Validation

5.1 Validation Methodology

To validate the effectiveness of the developed KQL rules, a testing environment was established using Microsoft Sentinel with simulated syslog telemetry from a Linux virtual machine connected via Azure Arc. The validation process consisted of three components:

5.2 Detection Accuracy Testing

Each KQL rule was tested against a dataset containing both known attack patterns and benign activities. The dataset included:

• Simulated authentication policy modification scenarios

• Kerberos SSO abuse simulations

• LDAP replication activity tests

• Privileged group modification tests

• Normal administrative activities for baseline comparison

5.3 False Positive Analysis

False positive rates were calculated by running each rule against production telemetry from a test hybrid environment. Rules with false positive rates exceeding 5% were tuned by adjusting thresholds and implementing additional exclusions.

5.4 Detection Results

The following table summarizes the validation results:

Table 1: Summary of KQL Rule Validation Results

Table 1: Summary of KQL Rule Validation Results

5.5 Performance Considerations

All rules demonstrated acceptable performance with query execution times under 30 seconds when running against 30 days of telemetry data. The AI-Assisted Reconnaissance rule showed the highest variation in alert volume based on organizational baseline.

6 Comparing Detection Efficiency

6.1 The Benchmarking Challenge

A strict benchmarking method is needed to assess the efficacy of unique KQL rules. Often unable to capture the whole detection engineering process are conventional techniques:

Knowledge Testing vs. Operationalization: Current cybersecurity standards mostly evaluate parametric knowledge can a model identify the MITRE technique behind a log entry? rather than the more difficult problem of whether detection logic can identify assaults in real data.

Standalone vs. Workflow Evaluation: Isolated rule testing misses the middle stages of detection engineering: reading threat intelligence, looking at telemetry, repeating query tweaking.

6.2 CTI-REALM: A Fresh Benchmarking Method

Microsoft’s CTI-REALM (Cyber Threat Real-World Evaluation and LLM Benchmarking) shows a lot of potential for determining how well detection engineering works [8, 9]: From start to finish, CTI-REALM assesses the whole detection engineering process: reading threat reports, looking at telemetry, writing and improving KQL queries, and generating validated detection rules.

Checkpoint-Based Scoring: Instead of a single total score, CTI-REALM offers checkpointbased scoring that shows if a model struggles with CTI understanding, question building, or detection accuracy.

Agents employ the same tools security analysts depend upon: CTI repositories, schema explorers, Kusto query engines, and MITRE ATT&CK databases.

6.3 Using Hybrid AD Detection Benchmarking

Hybrid AD evasion detection should be measured mostly on:

Method Coverage: Calculating the percentage of MITRE ATT&CK techniques for which detection rules have been put into practice. Research reveals that several companies have major holes in their ATT&CK coverage [10].

Evaluating detection rules for false positive rates, alert fatigue, and investigation efficiency helps to determine their quality.

Time-to-Detection: Assessing how rapidly detections spot post-compromise activity, especially for evasion methods that leave little audit trail.

6.4 Methodical Approaches to Benchmarking

For companies devoid of CTI-REALM, manual benchmarking still works:

Using the technique ID to find pertinent KQL rules from open-source repositories will help you to find the correct methodology. One study created a Python tool to extract KQL rules from 969 open-source rules so that businesses may include them in Microsoft Sentinel settings.

Generating MITRE ATT&CK Navigator heatmaps will help to see detection coverage and pinpoint holes. Though open-source identification is available, this strategy exposes methods inside the company devoid of detection controls.

Ground Truth Validation: Evaluating efficacy of detection rules by testing them against known attack telemetry and simulated attack situations.

7 New Directions and Emerging Trends

7.1 Augmented AI Detection Engineering

AI for detection engineering is being adopted at an ever-faster rate:

For KQL, generative artificial intelligence (AI) models may now create KQL queries from natural language descriptions of possible threat situations, therefore speeding up detection creation.

Automated Rule Refinement: Using testing data, AI agents may repeatedly improve their detection rules, therefore maximizing performance and accuracy.

AI may convert narrative threat intelligence into operational detection logic, therefore closing the divide between threat reports and detection rules.

7.2 Restrictions and Considerations

These developments still have significant restrictions, though:

Human oversight needed: Before operational deployment, AI-generated detection rules need human evaluation and validation.

Data Dependency: Available telemetry influences detection capability; many hybrid AD evasion methods produce very little audit traffic.

Evasion Evolution: Opponents change their strategies as detection methods get better, so generating a feedback loop of detection engineering.

8 Conclusion

8.1 What We Accomplished

This work set out to tackle a growing problem: how do you detect attackers who are moving between on-premises Active Directory and cloud environments without leaving obvious traces? After analyzing the latest attack techniques — many of which were only recently demonstrated at Black Hat USA 2025 — we built and tested five KQL detection rules specifically designed to catch post-compromise activity that traditional tools often miss.

Here is what we achieved:

First, we identified three particularly dangerous attack techniques: Seamless SSO key manipulation, Exchange hybrid certificate abuse, and low-privilege cloud account escalation. What makes these techniques so concerning is that they exploit the trust relationships between on-premises and cloud identity services in ways that don’t generate obvious audit logs. An attacker can essentially impersonate any hybrid user without triggering a single alert.

Second, we developed five KQL detection rules that look for behavioral patterns rather than relying on static signatures. These rules are tailored for Linux syslog telemetry because many hybrid AD attacks — especially those involving Kerberos and LDAP — leave traces in syslog data. We validated these rules in a lab environment using Azure Sentinel with syslog data from an Ubuntu VM running in VMware. The results were promising: detection rates ranged from 85% to 94%, and false positive rates stayed between 2% and 5%. These numbers suggest the rules are not just theoretically sound but practically useful for security operations teams.

Third, we documented a systematic methodology that other security teams can follow to develop their own detection rules. The process — threat modeling, telemetry analysis, rule development, and validation — is repeatable and adaptable. Organizations don’t have to start from scratch; they can use our approach as a blueprint for building detection coverage against emerging threats.

Finally, we explored where the field is heading. AI-assisted detection engineering is gaining momentum, and benchmarks like CTI-REALM are starting to evaluate how well AI agents can generate detection rules. While these tools show promise, they still require human oversight. We see a future where AI accelerates detection development, but human analysts remain essential for validation and tuning.

8.2 What This Means for Security Teams

If you are running a hybrid environment with Active Directory and Entra ID, the KQL rules we provide are a solid starting point. They are not meant to be copy-pasted and forgotten — they are meant to be adapted. Every organization has its own baseline of normal activity, so thresholds and exclusions will need tuning. That said, our validation results show that with proper configuration, these rules can catch real post-compromise behavior while keeping alert volumes manageable.

Beyond the rules themselves, the methodology we followed is probably just as valuable. Detection engineering is as much about process as it is about code. By understanding how we approached threat modeling and telemetry analysis, other teams can apply the same thinking to threats we haven’t covered in this paper.

8.3 Where We Fell Short

No research is without limitations, and we want to be upfront about ours:

First, our validation was limited to simulated syslog data from a single Ubuntu environment. In the real world, production environments are messier. Log volume is higher, log formats vary, and legitimate administrative activity can look a lot like an attack. Our false positive rates might increase in noisier environments.

Second, our test dataset didn’t fully capture the complexity of real adversarial behavior. Attackers are creative, and they often mix legitimate actions with malicious ones to blend in. We simulated known attack patterns, but we didn’t simulate the full range of evasion tactics that a sophisticated adversary might use.

Third, our rules only cover Linux syslog telemetry. That’s an important piece of the puzzle, but it’s not the whole picture. Windows Event Logs, Azure AD audit logs, and Microsoft 365 unified audit logs contain critical signals that we haven’t addressed. Comprehensive detection requires coverage across all these sources.

Fourth, our lab environment — Azure Sentinel free trial and VMware — is not equivalent to an enterprise-scale deployment. Performance, data processing, and integration challenges might look different in a large organization.

Finally, while our detection rates are encouraging, they are based on simulated scenarios. Real-world performance may vary, and organizations should test these rules against their own telemetry before relying on them operationally.

8.4 What’s Next

There is plenty of work left to do, and we see several promising directions:

We need to expand our rule coverage to include Windows Event Logs, Azure AD audit logs, and Microsoft 365 logs. Hybrid AD detection is only effective when you can see both sides of the environment, and right now we are only looking at one piece.

We also want to integrate our rules into the CTI-REALM benchmarking framework. It would be fascinating to see how AI-generated detection rules compare to the ones we built manually. If AI can match or exceed human performance, detection engineering could be transformed.

Some attack techniques — especially Seamless SSO key manipulation — generate almost no audit logs during exploitation. We need to develop detection strategies for these audit-log-free techniques. This might involve looking at secondary indicators or building detection logic around pre- and post-exploit activity.

Long-term operational performance is another open question. How well do these rules hold up over months of real-world use? Do they degrade as environments evolve? We need longitudinal studies to answer these questions.

We should also measure the return on investment of detection engineering. How much does a good detection rule reduce mean-time-to-detection? How much analyst time does it save by reducing false positives? These are practical questions that security leaders care about.

Finally, we see value in building automated tuning mechanisms. Instead of manually adjusting thresholds, what if detection rules could learn from an organization’s baseline behavior and adapt over time? That would reduce false positives and make detection more resilient to changing environments.

8.5 Wrapping Up

The hybrid threat landscape is moving fast, and attackers are not waiting for defenders to catch up. As more organizations adopt cloud identity services while keeping their on-premises Active Directory infrastructure, the attack surface grows, and the trust relationships between these environments become prime targets.

Traditional detection approaches — especially those that rely on static signatures — are struggling to keep up. Attackers are exploiting the seams between on-premises and cloud, often leaving minimal evidence behind. The way forward is behavior-based detection that looks for anomalies rather than known patterns.

This research is our contribution to that effort. We have provided validated KQL rules, a systematic methodology, and a forward-looking perspective on AI-driven detection engineering. But the real work happens when security teams take these artifacts, adapt them to their own environments, and refine them over time.

The rules and code from this research are available in the GitHub repository associated with this paper. We hope they serve as a useful resource for the security community, and we look forward to seeing how others build on this work.

After all, detection engineering is not a one-time task — it is a continuous cycle of learning, adapting, and improving. And in a world where attackers are constantly evolving, that is exactly the mindset we need.

References

[1] Mollema, D. (2025, August). Advanced Active Directory to Entra ID Lateral Movement Techniques [Conference Presentation]. Black Hat USA 2025, Las Vegas, NV. https://i.blackhat.com/BH-USA-25/Presentations/US-25-Mollema-AdvancedAD-to-Entra-ID-lateral-movement-techniques-Wednesday.pdf

[2] Black Hat USA 2025. (2025, August). Advanced Active Directory to Entra ID Lateral Movement Techniques [Video Presentation]. Black Hat USA 2025, Las Vegas, NV. https://www.classcentral.com/course/youtube-black-hat-usa-2025advanced-active-directory-to-entra-id-lateral-movement-techniques-530036

[3] HEAL Security. (2025, August). New Active Directory Lateral Movement Techniques that Bypasses Authentication and Exfiltrate Data. https://healsecurity.com/newactive-directory-lateral-movement-techniques-that-bypasses-authentication-andexfiltrate-data/

[4] LinkedIn. (2025, August). Active Directory Bypass Technique Exposed at Black Hat USA 2025. https://www.linkedin.com/posts/rajeshyadla

cybersecurityactivedirectory-entraid-activity-7359448330210283520-cLK5

[5] Digital Watch Observatory. (2025, August). Black Hat Demo Reveals Risks in Hybrid Microsoft Environments. https://dig.watch/updates/black-hat-demo-revealsrisks-in-hybrid-microsoft-environments

[6] Chougale, P. (2025, August). New Attack Vectors in Microsoft On-prem and Azure Authentication Protocols [LinkedIn Post]. https://www.linkedin.com/posts/prajwalchougale-4101b7213 new-attack-vectors-activity-7364532024935665664–3ajg

[7] Patel, K. (2025, March 11). Exploiting Active Directory Certificate Services (AD CS). Redfox Cybersecurity. https://www.redfoxsec.com/blog/exploiting-activedirectory-certificate-services-ad-cs

[8] CTI-REALM: A New Benchmark for End-to-End Detection Rule Generation with AI Agents. (2026, March). AzureFeeds. https://azurefeeds.com/2026/03/21/cti-realma-new-benchmark-for-end-to-end-detection-rule-generation-with-ai-agents/

[9] Argon Systems. (2026, March). CTI-REALM: A New Benchmark for End-to-End Detection Rule Generation with AI Agents. https://argonsys.com/author/arjunchakraborty/

[10] CardinalOps. (2025). 2025 State of SIEM Detection Risk Report. https://cardinalops.com/wp-content/uploads/2025/06/25-CardinalOps-2025State-of-SIEM-Report.pdf

[11] Beek, K. (2025, June). SIEMs Missing the Mark on MITRE ATT&CK Techniques. Dark Reading. https://www.darkreading.com/cybersecurity-operations/siemsmissing-mark-mitre-techniques

[12] AttackIQ Academy. (n.d.). Detection Management: From Entropy to Evidence.

https://www.academy.attackiq.com/courses/detection-management-from-entropyto-evidence

[13] Thoor, P. (2025). KQL Detections for Microsoft Security [GitHub Repository].

https://github.com/pthoor/detections-ai-kql


메타데이터
post_id
3376d0ad74fc
slug
developing-and-benchmarking-custom-kql-rules-for-3376d0ad74fc
url
https://medium.com/@shahzaibjanjua25/developing-and-benchmarking-custom-kql-rules-for-3376d0ad74fc
canonical_url
https://medium.com/@shahzaibjanjua25/developing-and-benchmarking-custom-kql-rules-for-3376d0ad74fc
author_url
https://medium.com/@shahzaibjanjua25
status
ok
fetched_at
2026-07-13 06:23:13