Reducing Domain and Cloud Exposure: Lessons from Red Team Assessments

Source context: this article examines information published by the source on August 25, 2026. This site’s publication date is shown separately. Check the latest vendor guidance before acting.

Research question and scope

This analysis examines how specific technical misconfigurations and gaps in vulnerability management allow attackers to escalate privileges from initial workstation access to full domain and cloud compromise. The scope covers Active Directory (AD), Active Directory Certificate Services (ADCS), Microsoft Entra ID, and the intersection of on-premises identity synchronization with cloud resources.

Key findings

The research identifies several critical exposure paths used to achieve administrative control across two different organizational environments:

• Active Directory Misconfigurations: The default Machine Account Quota (MAQ) of 10 was exploited, allowing unprivileged users to add computer accounts to the domain. Additionally, ESC1 misconfigurations in ADCS certificate templates enabled attackers to request certificates on behalf of any user or computer.
• Credential Exposure: Cleartext credentials were discovered in connections.json and product-preferences.xml files associated with SQL developer tools, as well as within SCCM distribution point XML files. Long-lived static AWS IAM user credentials were found in configuration files due to a lack of rotation or expiration policies.
• Cloud Identity Gaps: Microsoft Entra ID applications using ‘Application permissions’ were found to operate outside traditional Conditional Access Policies (CAPs). This allows attackers who compromise an application to bypass user-centric access controls unless ‘Conditional Access for workload identities’ is specifically implemented.
• Hybrid Identity Risks: The use of Entra ID Connect on-premises accounts (MSOL_) provided a path to obtain cleartext credentials via tools like ADConnectDump, facilitating movement from on-premises environments to the cloud.
• Infrastructure Weaknesses: Virtual desktops synchronized with a root Distributed File System (DFS) drive allowed attackers to access local files for thousands of users, bypassing the isolation typically associated with virtual sessions.

Potential breach-prevention strategy

In the reported cases, initial entry was achieved via web applications with default credentials and spearphishing. It remains unknown what specific EDR configurations or alert thresholds were in place at Organization A, though it is noted that medium- and low-severity alerts were ignored.

Our conditional analysis suggests a similar breach could have been mitigated through the following prioritized actions:

1. Restrict Machine Account Quota (MAQ): To address the risk of unprivileged users adding unauthorized computer accounts, the MAQ should be reduced to 0. Responsible Role: Domain Administrator. Verification: Attempt to create a machine account using a low-privileged user account; the action should be denied.
2. Remediate ADCS Template Misconfigurations: To prevent ESC1 attacks (requesting certificates for any user), certificate templates must be audited for improper enrollment permissions. Responsible Role: PKI Administrator / Vulnerability Manager. Verification: Use authorized scanning tools to identify templates where ENROLLEE_SUPPLIES_SUBJECT is enabled for non-administrative users.
3. Implement Conditional Access for Workload Identities: To prevent the exploitation of Application permissions in Entra ID, organizations should deploy CAPs specifically for service principals. Responsible Role: Cloud Security Architect. Verification: Review Entra ID policy logs to ensure that requests from service principals are subject to conditional access requirements.
4. Enforce Credential Rotation and Secret Management: To mitigate the risk of static AWS IAM keys or cleartext SQL credentials in config files, move secrets to a managed vault with automated rotation. Responsible Role: Infrastructure Lead / DevSecOps. Verification: Audit configuration files for hardcoded strings and verify that IAM keys have an expiration date set.

Controls 1, 2, and 3 are intended to prevent initial privilege escalation; control 4 is intended to limit the damage of a compromised workstation by removing high-value targets from the filesystem.

Security implications

The primary implication for security leaders is that traditional EDR alerts alone do not constitute a defense if they are obscured by noise or siloed across different SOC teams. Furthermore, the transition to cloud and hybrid identities introduces new exposure paths—such as workload identity permissions—that are not covered by standard user-based Conditional Access policies. The ability of an attacker to move from a compromised on-premises synchronization account (MSOL_) to the cloud highlights a critical dependency between on-premise hygiene and cloud security.

How to apply the findings

Defenders should prioritize the following validation steps to ensure exposure is actually reduced:
* Beyond Version Checks: Do not rely on software versions to prove mitigation. Instead, perform functional testing (e.g., attempting a machine account creation) to verify that the MAQ restriction is active.
* Audit DFS Permissions: Review the permissions of root DFS drives used by virtual desktops to ensure users cannot access other users’ home directories or configuration files.
* Review Service Account Privileges: Audit domain service accounts for excessive rights, specifically looking for AllExtendedRights on domain controllers, which could enable resource-based constrained delegation attacks.

Research limits

This analysis is based on red team simulations; results may vary based on specific network architectures and existing security stacks. The effectiveness of ‘Conditional Access for workload identities’ is presented as a theoretical mitigation since the red team did not encounter it in practice during these assessments. The findings regarding MSOL_ account permissions are subject to recent Microsoft deprecations, which may alter the exploitability of those accounts in current environments.

Source and editorial note

A Tale of Two SOCs: Insights From Two Red Team Assessments · Source date: August 25, 2026 · Retrieved August 31, 2026.

Material facts are tied to the cited primary source. Recommendations are independent defensive analysis unless attributed to the source. Confirm consequential decisions against current authoritative guidance.

Request a Vulnerability Assessment