Listen to this Post
Introduction:
In modern Active Directory and Azure AD environments, accurate attack path mapping is critical for prioritizing real risks. However, specialized middleware like Citrix can create dangerous blindspots by altering the fundamental meaning of common permissions. This article explores how BloodHound Enterprise (BHE) intelligently accounts for Citrix’s “Direct Access Users” group to prevent the misrepresentation of Remote Desktop Protocol (RDP) access, ensuring your defensive focus remains on truly exploitable paths.
Learning Objectives:
- Understand how Citrix Virtual Apps and Desktops (CVAD) change the security context of RDP permissions through the “Direct Access Users” group.
- Learn how to configure BloodHound Enterprise to correctly interpret and map Citrix-mediated access, removing misleading “CanRDP” edges.
- Master manual techniques to audit and verify Citrix RDP access controls outside of BHE using PowerShell and native Citrix tools.
You Should Know:
- The Citrix “Direct Access Users” Group: A Deny-by-Default Control
The core of the issue lies in a specific Citrix-created Active Directory group. When Citrix Virtual Apps and Desktops are deployed, it often creates a group named “Direct Access Users” (the exact name may vary). This group is part of a deny-by-default security model: if a user is not in this group, they cannot establish a direct RDP connection to the underlying Citrix Virtual Delivery Agent (VDA) host, even if they have the standard “Allow log on through Remote Desktop Services” user right assignment. Their access is only mediated through the Citrix connection broker.
Step-by-Step Guide to Identify the Group:
First, defenders must locate this critical group within their environment.
1. On a Domain Controller or machine with RSAT tools, open PowerShell as an administrator.
2. Use Active Directory PowerShell module to search for groups with “Direct Access” in the name:
Get-ADGroup -Filter {Name -like "Direct Access"} -Properties Description | Select-Name, DistinguishedName, Description
3. To see which users are explicitly granted direct access, enumerate the group’s members:
$GroupName = "Citrix Direct Access Users" Adjust based on your environment Get-ADGroupMember -Identity $GroupName -Recursive | Get-ADUser -Properties Name, SamAccountName | Select Name, SamAccountName
This group’s existence signals that RDP permissions are gated by Citrix policy, not just Windows local security policy.
2. How BloodHound Enterprise Corrects the Graph
Without context, a user with the “Remote Desktop Users” membership on a Citrix VDA would generate a “CanRDP” edge in BloodHound, implying a direct path to compromise that host. BHE’s Citrix RDP Support feature detects the presence of the relevant Citrix control group and removes those edges, as they do not represent a true, direct compromise path. The attacker would first need to compromise the Citrix infrastructure itself.
Step-by-Step Guide to Enable BHE Citrix Support:
- Log in to your BloodHound Enterprise tenant as an administrator.
2. Navigate to Administration > BloodHound Configuration.
3. Locate the setting for “Citrix RDP Support”.
- Toggle the feature to “Enabled”. This instructs BHE’s data ingestion and path-finding engines to parse for Citrix control groups and adjust the graph logic accordingly.
- Ensure a new data collection is run from your collectors to reprocess the environment with this new logic. Paths visible in the UI will now reflect the accurate, Citrix-aware state.
3. Manually Auditing the True RDP Attack Surface
Security teams should not rely solely on tools. Manual verification is key.
Step-by-Step Guide for Manual RDP Audit on a Citrix VDA:
1. Check Local “Remote Desktop Users” Group:
On the VDA host (Windows) net localgroup "Remote Desktop Users"
This lists users with the potential Windows permission.
- Cross-Reference with Citrix Group Membership: Compare the list from Step 1 against the members of the “Citrix Direct Access Users” group obtained earlier. Users appearing in the local group but NOT in the Citrix group have their RDP access blocked by Citrix.
- Verify via Citrix Policy: In the Citrix Studio management console, navigate to Policies. Look for a policy containing settings like “Direct HDX connections” or “Direct connections to VDA”. The rule filtering is likely based on the “Direct Access Users” group.
4. Exploiting & Mitigating Misconfigured Citrix RDP Controls
The vulnerability arises if the “Citrix Direct Access Users” group is misconfigured—either being deleted, improperly scoped, or over-permissioned. An attacker who compromises a user in this group gains a powerful, often overlooked, lateral movement path directly into a sensitive VDA.
Step-by-Step Mitigation Hardening Guide:
- Inventory: Document all Citrix VDA servers and their associated “Direct Access” groups using the PowerShell commands above.
- Least Privilege Audit: Review membership of each “Direct Access Users” group. It should contain only administrative or break-glass accounts, not standard users. Remove any unnecessary members.
Remove-ADGroupMember -Identity "Citrix Direct Access Users" -Members "OverprivilegedUser" -Confirm:$false
- Backup Control: Ensure a secondary network-layer control (e.g., Windows Firewall rules or network segmentation) restricts RDP (TCP/3389) traffic to Citrix VDAs only from approved Citrix infrastructure (Connection Servers, Gateways), not from general user subnets. This provides defense-in-depth.
5. Integrating with Cloud-Hosted Citrix (Citrix DaaS)
The principle extends to cloud-delivered Citrix DaaS. The control group and policy exist within your on-premises Active Directory or Azure AD that the VDA registers with.
Step-by-Step Guide for Azure AD Integrated Environments:
- The “Direct Access Users” group may be an Azure AD Security Group.
2. Query using Microsoft Graph PowerShell:
Connect-MgGraph -Scopes "Group.Read.All" Get-MgGroup -Filter "displayName eq 'Citrix Direct Access Users'" -ConsistencyLevel eventual
3. Map membership and ensure it is synchronized correctly to your VDAs via Azure AD Connect or native Azure AD join/registration.
4. The hardening steps remain conceptually identical: enforce least privilege on this cloud group.
What Undercode Say:
- Context is King in Attack Pathing: The most powerful security tools are those that understand the business and technical context of permissions, not just the raw data. BHE’s logic update exemplifies moving from generic graph theory to applied security intelligence.
- Middleware Creates Critical Abstraction Layers: Citrix, VPNs, PAM solutions, and cloud brokers insert a critical layer between the user and the resource. Security teams must map these “gating” controls with the same rigor as native OS permissions, or they will constantly fight false positives and miss real paths.
Analysis: SpecterOps’ enhancement to BloodHound Enterprise is a significant step towards context-aware security posture management. It addresses a classic problem in enterprise security: the map not matching the territory. By modeling the deny-by-default behavior of a major platform like Citrix, BHE reduces alert fatigue and helps defenders concentrate on attack paths that are genuinely exploitable. This move signals a trend where advanced security tools will increasingly need integrated knowledge of common enterprise middleware and SaaS platforms. The manual verification steps remain crucial, as they build institutional knowledge and catch edge cases or misconfigurations that any automated tool might miss. Ultimately, this synergy between human-driven audit and intelligent tooling creates a more resilient defense.
Prediction:
The future of Attack Path Management (APM) and Identity Threat Detection and Response (ITDR) will be dominated by platforms that deeply integrate logic for major enterprise software ecosystems. We will see similar “connectors” or “plugins” for platforms like SAP, Oracle E-Business Suite, VMware Horizon, and cloud-native PAM solutions. The next frontier is automated detection of misconfigurations within these middleware layers—such as an over-permissioned Citrix Direct Access group—and directly flagging them as high-severity risks, potentially even auto-remediating by suggesting precise least-privilege fixes. This will evolve APM from a static map into a dynamic, self-healing security control plane.
▶️ Related Video (76% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Bloodhoundbasics Share – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
