11. Identity, Active Directory and Enterprise Attack Paths

Introduction and Context

Enterprise compromise is frequently described as a problem of vulnerable servers, exposed applications, or malicious software. In practice, however, many serious intrusions are identity problems. An attacker who obtains a valid account, abuses an excessive privilege, or discovers an unintended trust relationship may move through an environment without exploiting a traditional software vulnerability. Identity has therefore become the principal control plane of enterprise security.

Identity security concerns the complete lifecycle of subjects and resources: establishing who a user or service is, authenticating that identity, assigning permissions, recording activity, and withdrawing access when it is no longer justified. In Microsoft-centred environments, Active Directory Domain Services (AD DS) commonly provides the directory, authentication, policy, and trust mechanisms on which business operations depend. Its importance also makes it a high-value target. A weakness in a domain administrator account, a misconfigured delegation right, or an exposed service credential can create an attack path from an ordinary workstation to the enterprise’s most sensitive systems.

This chapter examines identity architecture from an ethical-hacking and penetration-testing perspective. It does not treat directory security as a collection of isolated configuration checks. Instead, it presents identity as a graph of relationships: users belong to groups, groups control resources, computers host sessions, services use accounts, and domains establish trusts. The tester’s task is to determine whether these relationships permit an attacker to progress toward a defined objective. The defender’s task is to reduce unnecessary relationships, protect authentication material, detect abuse, and ensure that administrative authority is limited, temporary, and accountable.

The discussion assumes an authorized assessment. Directory testing can affect authentication services, endpoints, business applications, and regulated information. Scope, rules of engagement, evidence handling, and emergency contacts must therefore be established before technical activity begins.

Learning Objectives

After completing this chapter, the reader should be able to:

1. Explain the architecture and security roles of enterprise identity systems and AD DS.

2. Distinguish authentication, authorization, accounting, federation, and directory services.

3. Interpret Kerberos, NTLM, LDAP, group policy, delegation, trust, and service-account risks.

4. Model privilege relationships and identify practical enterprise attack paths.

5. Plan an authorized identity-focused penetration test using safe discovery and validation methods.

6. Evaluate credential exposure, excessive privilege, and misconfiguration without overclaiming impact.

7. Recommend identity-hardening, monitoring, governance, and zero-trust controls.

Identity as an Enterprise Control Plane

An identity system answers several different questions. Authentication asks whether a subject can prove control of an identity. Authorization asks what that identity may do. Accounting records what occurred and supports investigation. Identification associates an action with a named principal, although identification alone does not prove that the principal is genuine. These functions are related but must not be confused. A correct username is identification; a successfully validated password, certificate, or token is authentication; permission to modify a database is authorization.

A useful enterprise identity model contains five interacting layers:

• Subjects: human users, administrators, applications, devices, service accounts, and workload identities.
• Credentials and authenticators: passwords, hashes, tickets, certificates, hardware-backed keys, tokens, and biometric factors.
• Directories and identity providers: systems that store attributes, group memberships, policies, and trust information.
• Policy and authorization: access-control lists, group-based permissions, claims, conditional access, and privileged access rules.
• Telemetry and governance: logs, identity lifecycle processes, access reviews, separation of duties, and incident response.

Security failures often occur at the boundaries between these layers. For example, a directory may be well configured while a service stores a domain credential in a script. Similarly, multi-factor authentication may protect remote access but not a legacy internal protocol that accepts only a password hash.

Identity also has a lifecycle. Joiner, mover, and leaver processes determine whether access is granted, changed, or removed as a person’s role changes. Weaknesses in these processes create dormant accounts, privilege accumulation, orphaned service accounts, and inconsistent ownership. From a penetration-testing viewpoint, lifecycle weaknesses are often more significant than a single technical configuration error because they persist across systems and business units.

Active Directory Architecture and Security Boundaries

AD DS is a distributed directory service based on LDAP and integrated with Windows authentication and policy mechanisms. A typical deployment includes domain controllers, member servers, workstations, organizational units (OUs), users, groups, computers, and service accounts. Objects have attributes, security identifiers, and access-control descriptors. Domain controllers replicate directory data, authenticate principals, and commonly provide Kerberos services.

A domain is an administrative and authentication boundary, although it is not automatically a complete security boundary. A forest is a collection of one or more domains sharing a schema, configuration, and implicit trust relationships. A tree is a related hierarchy of domains within a forest. OUs are logical containers used for administration and Group Policy application; they are not, by themselves, isolation boundaries. A site represents network topology and helps control replication and service location.

The distinction between administrative and security boundaries is crucial. An organization may place users in separate OUs and believe that this prevents compromise from spreading. In reality, permissions, group nesting, delegated administration, trusts, and shared credentials may connect those OUs. A forest compromise can affect every domain within it, while a poorly governed external trust can extend risk beyond the organization’s direct administrative control.

Security identifiers (SIDs) identify security principals. Access-control entries (ACEs) specify allowed or denied operations for principals, and discretionary access-control lists (DACLs) collect those entries. System access-control lists (SACLs) specify auditing. Effective access is the result of object ownership, explicit permissions, inherited permissions, group membership, deny rules, delegation, and the protocol used to reach the resource. A permission that appears harmless in isolation may be highly consequential when combined with another relationship.

Group Policy provides centralized configuration and security settings. Group Policy Objects (GPOs) can apply user rights, software settings, scripts, firewall policies, and restrictions to computers or users. Because GPOs operate broadly, control over a GPO linked to privileged systems may provide an indirect path to administrative control. The security question is not simply whether a user can edit a GPO, but which systems receive it and what actions the policy can perform.

Authentication Protocols and Credential Exposure

Kerberos

Kerberos is the principal authentication protocol in modern AD environments. A user initially authenticates to the Key Distribution Center (KDC), normally hosted on a domain controller, and receives a Ticket Granting Ticket (TGT). The user then requests service tickets for specific services. This reduces the need to send the user’s password to each service and supports mutual authentication in appropriate configurations.

Kerberos security depends on time synchronization, protection of the KDC, strong account secrets, correct service principal names (SPNs), and appropriate delegation settings. A service account associated with an SPN may become an attractive target because its secret supports service authentication. Weak service-account passwords, excessive privilege, unconstrained delegation, and poorly controlled delegation relationships can turn a legitimate authentication feature into an attack path.

Kerberos also creates investigative challenges. A valid ticket may allow access without a new interactive logon, so defenders need correlation among ticket events, endpoint activity, process creation, and network behavior. Ticket lifetime and renewal settings matter, but shortening them is not a substitute for protecting the underlying account and endpoint.

NTLM

NTLM is an older challenge-response protocol retained for compatibility. It lacks several security properties of Kerberos and is susceptible to relay, credential capture, and password-hash-related abuse under unsuitable conditions. The risk is not limited to the protocol itself. Unsigned or weakly protected protocols such as SMB, LDAP, or HTTP may allow an attacker to relay an authentication attempt to another service.

A mature assessment identifies where NTLM is still required, whether signing and channel binding are enforced, and whether legacy applications can be modernized. Disabling NTLM abruptly can interrupt business operations; reduction therefore requires dependency discovery, staged policy changes, and exception governance.

LDAP, certificates, and federation

LDAP provides directory query and modification functions. Clear-text or improperly protected LDAP exposes credentials and directory data. LDAP signing and channel binding help prevent tampering and certain relay conditions. Certificate-based authentication can strengthen identity assurance, but certificates introduce their own risks: weak certificate templates, excessive enrollment rights, exportable private keys, and inadequate revocation. In federated environments, Security Assertion Markup Language, OAuth, and OpenID Connect transfer authentication or authorization assertions between systems. A compromised identity provider, signing key, application registration, or token-validation process can affect many relying parties at once.

Privilege Relationships and Attack-Path Analysis

Traditional vulnerability scanning asks whether a host or application contains a known weakness. Attack-path analysis asks whether a sequence of individually permitted relationships can produce an unacceptable outcome. It is therefore closer to graph analysis than to checklist auditing.

In an identity graph, nodes may represent users, groups, computers, domains, applications, secrets, and sensitive resources. Edges represent relationships such as “member of,” “can log on to,” “has control over,” “can reset password,” “can edit policy,” “runs service,” or “trusts.” A path becomes especially important when it ends at a high-value asset and every transition is feasible for the attacker’s assumed starting position.

Common path patterns include:

• An ordinary user can read a script containing a service credential; the service account is a member of a privileged group.
• A workstation administrator can access a machine where a privileged administrator has an active session; credential material or delegated access then becomes exposed.
• A low-privilege group can modify a GPO linked to domain controllers or administrative workstations.
• A user can reset the password of a service account, or write an attribute that changes the account’s effective privileges.
• An account with local administrative rights can compromise a server hosting a database, application, or identity-management connector.
• An external trust permits authentication from a less protected domain into a sensitive resource domain.

The validity of a path depends on context. A theoretical permission may not be exploitable because the object is disabled, network access is blocked, or a required protocol is unavailable. Conversely, a modest permission may be severe when it affects a highly privileged object. Testers should document preconditions, required privileges, reliability, business impact, and detection opportunities for every path.

Privilege tiers and administrative separation

A tiered administrative model separates control of domain infrastructure, servers, workstations, and ordinary user accounts. The objective is to prevent a compromise at a lower tier from exposing credentials capable of controlling a higher tier. Administrative workstations, dedicated accounts, restricted logon rights, and separate management networks support this model.

Tiering is not a label applied to groups alone. If a domain administrator regularly logs on to an ordinary workstation, the technical separation has failed even if the account is named “Tier 0.” Privileged access must be evaluated through session placement, endpoint trust, delegation, remote-management paths, and recovery procedures.

BloodHound-style graph analytics

Graph-oriented tools can collect directory relationships and calculate likely paths to objectives. Such tools are valuable for prioritization because they reveal combinations that ordinary configuration reports miss. They must be used carefully: collection can create sensitive data, graph output can be misunderstood, and aggressive collection may affect systems or violate privacy expectations. An assessment should minimize data, protect exports, validate important findings manually, and report business meaning rather than merely presenting a graph image.

Credential Exposure and Secret Governance

Credentials are exposed in many locations: browser stores, memory, scheduled tasks, scripts, deployment files, configuration management systems, backup archives, ticketing systems, logs, crash dumps, and developer repositories. The danger depends on credential type, privilege, reuse, lifetime, and the systems reachable by the identity.

Password reuse allows compromise to cross administrative boundaries. Shared accounts destroy accountability and complicate revocation. Service accounts often have long-lived passwords, interactive logon rights, broad permissions, and no human owner. Managed service accounts and group managed service accounts can reduce password-management risk by automating secret rotation and restricting usage, although their permissions still require review.

Secrets management should use a controlled vault, narrowly scoped access, rotation, expiration, audit trails, and workload identity where practical. A secret found during a test must not be copied unnecessarily or used beyond the agreed validation step. The tester should prove impact with the least invasive action and report the location, type, exposure condition, and recommended remediation without disclosing the secret in ordinary deliverables.

A Method for Authorized Identity Penetration Testing

An identity-focused assessment should combine architecture review, configuration analysis, controlled technical validation, and attack-path reasoning.

Establish scope and objectives

Define starting privileges, in-scope domains, identity providers, cloud connections, test accounts, prohibited actions, acceptable load, and rules for handling personal or authentication data. Agree whether the objective is control validation, path discovery, resilience assessment, or an assumed-breach exercise.

Build an identity inventory

Map domains, forests, trusts, domain controllers, privileged groups, administrative workstations, service accounts, certificate authorities, identity synchronization tools, remote-access services, and critical applications. Identify owners and dependencies. An inventory that excludes non-Windows identity providers or cloud directories is incomplete in a hybrid enterprise.

Collect and interpret evidence

Review group memberships, delegation, ACLs, GPO links, authentication policies, service principal names, logon restrictions, trust configuration, certificate templates, password and lifecycle controls, and relevant event logs. Use read-only collection wherever possible. Compare effective permissions rather than relying only on intended role descriptions.

Validate high-value paths

Select a small number of paths that represent material risk. Confirm reachability and authorization with controlled techniques. Avoid destructive changes, password spraying, persistence, or credential extraction unless specifically approved. Validation should answer: Can the starting identity reach the next node? What exact permission enables the transition? What asset is affected? What evidence would demonstrate compromise? What control would break the path?

Report and remediate

Rank findings by business impact, exploitability, exposure, and remediation effort. A strong report distinguishes a confirmed compromise from a theoretical possibility. It includes a path narrative, affected identities and assets, evidence, detection opportunities, immediate containment, structural remediation, and a retest plan. After remediation, recalculate paths rather than checking only whether one permission disappeared.

Defensive Architecture and Zero-Trust Controls

Zero trust is not a single product or a claim that no user is trusted. It is a decision model in which access is continuously evaluated using identity, device condition, resource sensitivity, context, and policy. It assumes that network location is insufficient evidence of trust.

Important controls include phishing-resistant multi-factor authentication for privileged and high-risk access; privileged access management with approval, time limitation, session recording, and just-in-time elevation; separate administrative accounts; hardened administrative workstations; restricted privileged logon paths; and strong recovery procedures. Conditional access should consider device health, location anomalies, authentication strength, risk signals, and the sensitivity of the requested resource.

Directory hardening should include removal of stale accounts, least-privilege group design, review of nested groups, protection of domain controllers, secure LDAP, SMB signing where appropriate, reduction of NTLM, controlled delegation, managed service accounts, protected administrative groups, and careful GPO governance. Backup and recovery must be tested because identity systems are central to business continuity. A directory that is secure during normal operations but unrecoverable after ransomware remains a material risk.

Detection should focus on identity abuse rather than isolated events. Useful signals include unusual privilege changes, new delegation, anomalous ticket requests, authentication from atypical devices, impossible travel, repeated failures followed by success, new service-account use, changes to GPOs or certificate templates, and privileged logons to lower-tier assets. Analytics should be tuned to reduce false positives and linked to response playbooks.

Automation can continuously compare effective permissions with approved role models, identify dormant accounts, calculate shortest paths to crown-jewel assets, and detect toxic combinations of rights. Machine-learning systems may help prioritize anomalies, but their conclusions require human validation. Automated remediation can cause outages if it removes a permission used by a critical application; change control and rollback are essential.

Illustrative Case Study: The Path from a Help-Desk Account to Domain Control

Background

A fictional regional logistics company operates a single AD forest with approximately 2,000 employees. The help-desk team uses a delegated group to reset passwords and unlock accounts. Administrators manage servers remotely from ordinary corporate laptops. Several legacy applications still support NTLM. The company has deployed multi-factor authentication for external remote access but not for all internal administrative activity.

Situation and problem

During an authorized assumed-breach assessment, the testers receive credentials for a standard help-desk user. They are asked to determine whether the account can reach domain-level administrative functions without disrupting operations. The organization believes that password-reset delegation is limited to ordinary users.

Analysis

Read-only directory analysis shows that the help-desk group can reset passwords for a service account used by an inventory application. The service account is a member of a server-local administrators group on an application server. A domain administrator regularly administers that server from a standard laptop. The server also permits an older authentication path that lacks adequate signing protection.

The assessment identifies a chain of relationships: help-desk delegation leads to control of the service account; service-account control leads to local administration of the application server; the server becomes a high-value credential exposure point because of privileged administrative sessions; and the legacy authentication configuration increases the possibility of credential relay or interception. No destructive action is taken, and no administrator credential is extracted.

Approach and solution

The testers document each edge, verify that the delegated password-reset permission is effective, and demonstrate only that the service account can authenticate to the application server under controlled conditions. They do not change production passwords. The report recommends removing unnecessary service-account group membership, converting the workload to a managed service identity, restricting interactive and remote logon rights, separating administrative workstations from ordinary endpoints, enforcing signing and stronger authentication protocols, and reviewing all delegated password-reset permissions.

The company also introduces time-limited privileged access, requires phishing-resistant MFA for administrators, and creates an approval process for changes to GPOs, delegation, certificate templates, and privileged groups. Detection rules are added for unusual service-account use and administrative logons from non-administrative workstations.

Outcome

The original path is broken at several points rather than by a single compensating control. The service account no longer possesses unnecessary server-local administration, privileged sessions are prohibited on ordinary laptops, and legacy authentication dependencies are placed under a migration plan. A retest confirms that the help-desk account cannot reach the former objective through the documented route.

Learning points

The case illustrates that identity risk is relational. Password-reset delegation, service-account privilege, administrative session placement, and legacy protocol support each appeared manageable in isolation. Together they formed a practical path. It also demonstrates why multi-factor authentication at the perimeter cannot compensate for weak internal privilege relationships, and why remediation should remove structural causes rather than merely monitor the final stage of an attack.

Challenges, Limitations, and Common Mistakes

Identity assessments face several limitations. Directory data may be incomplete, cloud and on-premises identities may be synchronized inconsistently, and effective permissions can change during the test. A graph tool may report a path that is technically valid but operationally blocked; conversely, undocumented credentials or application behavior may create paths not visible in directory data.

Common mistakes include treating group membership as the only form of privilege, ignoring object ownership and delegated rights, assuming OUs provide isolation, testing only perimeter MFA, overlooking service accounts, and reporting every theoretical path as a critical vulnerability. Other errors include collecting excessive credential material, using production accounts without safeguards, failing to coordinate with identity operations, and recommending immediate protocol disablement without dependency analysis.

A further challenge is organizational ownership. Human resources, infrastructure, application, cloud, security, and audit teams may each control part of the identity lifecycle. Without a defined identity owner and measurable access-review process, technical findings recur. Metrics should include stale privileged accounts, time to revoke leaver access, percentage of privileged access protected by strong MFA, number of unmanaged service accounts, and count of unresolved high-risk paths to critical assets.

Ethical, Governance, and Professional Considerations

Identity testing involves sensitive personal and organizational data. Testers should follow authorization boundaries, data-minimization principles, confidentiality requirements, and applicable privacy and cybersecurity law. Passwords, tokens, hashes, private keys, and directory exports should be encrypted, access-controlled, retained only as long as necessary, and securely destroyed.

Professional judgment is essential when a finding could affect availability. A tester should not reset a production administrator’s password, deploy persistence, dump credentials, or alter GPOs merely to make a report more convincing. Evidence should be sufficient, reproducible, and proportionate. Findings should be communicated to accountable owners, with urgent escalation for active exposure of critical identities.

Governance should establish separation of duties, periodic access certification, emergency access (“break-glass”) controls, documented exceptions, and independent review of privileged changes. Regulatory requirements may impose additional obligations for auditability, least privilege, breach response, or protection of personal and financial data. Compliance, however, is not equivalent to security; an organization may satisfy a review checklist while retaining a dangerous attack path.

Current Developments

Hybrid identity is now a central concern. Synchronization between on-premises directories and cloud identity providers creates both operational convenience and compound risk. A compromise of a synchronization agent, federation service, application registration, or privileged cloud role may cross environments. Organizations are increasingly adopting passwordless and phishing-resistant authentication, device-bound credentials, hardware security keys, workload identity, and identity threat detection.

Identity fabric initiatives seek to provide consistent policy across applications, clouds, APIs, machines, and human users. At the same time, non-human identities are expanding rapidly through containers, automation pipelines, robotic processes, and artificial-intelligence workloads. These identities require ownership, rotation, scope limitation, provenance, and monitoring just as human identities do. Short-lived tokens and workload attestation can reduce static-secret exposure, but poor authorization design can still grant excessive capability.

Attack-path management is also becoming continuous rather than periodic. Directories, cloud permissions, endpoint telemetry, and asset inventories can be combined to calculate changing routes to sensitive resources. The quality of such systems depends on accurate inventories, explainable analysis, and disciplined remediation; a large volume of alerts without ownership can become another form of risk.

Best-Practice Principles

1. Treat identity relationships, not isolated settings, as the unit of risk analysis.

2. Protect privileged identities with phishing-resistant MFA, separate accounts, hardened devices, and time-limited elevation.

3. Remove unnecessary delegation, nested group membership, service-account privilege, and interactive logon rights.

4. Prefer managed or workload identities and centrally governed secret storage over embedded, shared, long-lived credentials.

5. Reduce legacy authentication only through an inventoried, monitored, and staged migration.

6. Review trusts, GPO permissions, certificate templates, synchronization services, and administrative sessions as high-value control points.

7. Combine preventive controls with identity-focused detection, tested recovery, and continuous access review.

8. Validate remediation by recalculating attack paths and confirming that business requirements remain supported.

9. Handle directory and credential evidence as sensitive data and use the least invasive testing method.

10. Make identity security a shared governance responsibility with clear ownership and measurable outcomes.

Chapter Summary

Enterprise identity is the control plane through which users, devices, services, applications, and administrators gain access to resources. AD DS combines directory information, Kerberos authentication, policy, groups, ACLs, delegation, and trusts; these mechanisms can support security but can also create paths to broad compromise. Attack-path analysis models effective relationships and evaluates how a low-privilege starting point might reach a critical asset.

A professional assessment inventories identity architecture, examines authentication protocols and credential exposure, analyzes effective permissions and privilege tiers, validates carefully selected paths, and reports both impact and remediation. Strong defenses include least privilege, administrative separation, managed service identities, secure protocols, phishing-resistant MFA, privileged access management, lifecycle governance, monitoring, and tested recovery. Zero trust strengthens these practices by evaluating identity, device, context, and resource sensitivity continuously rather than relying on network location. The central lesson is that identity risk is cumulative: several ordinary permissions can combine into an extraordinary compromise.

Key Terms

Active Directory Domain Services (AD DS): Microsoft directory service providing identity, authentication, policy, and resource-management functions.

Authentication: Verification that a subject controls a claimed identity.

Authorization: Determination of the actions an authenticated identity may perform.

Kerberos: Ticket-based network authentication protocol widely used by AD environments.

NTLM: Legacy Windows challenge-response authentication protocol with significant relay and credential-exposure risks.

LDAP: Directory-access protocol used to query and manage directory information.

Security principal: An identity, such as a user, group, computer, or service, that can receive permissions.

Access-control entry (ACE): A rule granting or denying a particular permission to a principal.

GPO: Group Policy Object containing settings applied to users or computers.

Delegation: Assignment of authority to perform actions on another object or service.

Service account: Identity used by an application, scheduled task, or system service.

SPN: Service Principal Name identifying a service instance for Kerberos authentication.

Privilege tiering: Separation of administrative authority and logon environments by sensitivity.

Attack path: A sequence of feasible relationships leading from an attacker’s starting position to an objective.

Forest: AD structure containing one or more domains sharing core directory components and trust relationships.

Trust: Relationship allowing authentication or authorization across domains or identity boundaries.

Zero trust: Security approach that continuously evaluates access using identity, device, context, and resource sensitivity.

Privileged access management: Controls governing elevated access, including approval, time limitation, monitoring, and session control.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorization and accounting.

2. Why are OUs not necessarily security boundaries?

3. What security problems are associated with long-lived service accounts?

4. Explain the purpose of privilege tiering.

5. What is an attack path in an identity graph?

Long Answer Questions

1. Explain the security architecture of AD DS, including domains, forests, groups, ACLs, GPOs, and trusts.

2. Compare Kerberos and NTLM from a penetration-testing and defensive perspective.

3. Describe a complete methodology for conducting an authorized identity-focused penetration test.

4. Discuss how zero-trust principles can reduce enterprise identity attack paths.

5. Explain why service accounts, delegation, and administrative session placement must be analyzed together.

Analytical / Application Questions

1. A help-desk group can reset a service account’s password, and that account is a local administrator on a server used by domain administrators. Model the attack path and recommend controls that would break it at multiple points.

2. An organization has enabled MFA for external VPN access but permits administrators to use ordinary laptops for internal server management. Analyze the residual identity risk and propose a tiered control design.

3. A graph tool identifies a path to domain control through a GPO. Explain what evidence you would collect before rating the finding as critical and how you would validate it safely.

22. Multiple Choice Questions with Answers

Question 1

Which statement best describes an enterprise attack path?

A. A list of all vulnerabilities detected on a server

B. A sequence of feasible identity or privilege relationships leading to an objective

C. A record of every successful user authentication

D. A network route between two domain controllers

Correct Answer: B. A sequence of feasible identity or privilege relationships leading to an objective

Question 2

Why can control over a GPO linked to privileged systems be especially dangerous?

A. A GPO automatically reveals every user password

B. A GPO can apply configuration, scripts, or rights broadly to affected systems

C. A GPO disables all authentication controls by design

D. A GPO creates a new forest administrator account automatically

Correct Answer: B. A GPO can apply configuration, scripts, or rights broadly to affected systems

Question 3

Which condition most directly increases the risk posed by a service account?

A. It has a randomly generated, regularly rotated secret and limited rights

B. It is prevented from interactive logon and used only by one workload

C. It has a long-lived password, broad privilege, and interactive logon rights

D. It is monitored by an identity-management platform

Correct Answer: C. It has a long-lived password, broad privilege, and interactive logon rights

Question 4

What is the principal security concern with relying on NTLM where stronger alternatives are available?

A. It cannot operate on any Windows network

B. It may enable credential capture or relay under weak protocol protections

C. It requires a public certificate authority for every login

D. It prevents all forms of centralized authentication

Correct Answer: B. It may enable credential capture or relay under weak protocol protections

Question 5

Which practice best reflects privilege tiering?

A. Using one administrator account for all systems to simplify auditing

B. Allowing domain administrators to log on routinely to ordinary workstations

C. Separating high-sensitivity administrative accounts, devices, and logon paths

D. Placing all users in one large administrative group

Correct Answer: C. Separating high-sensitivity administrative accounts, devices, and logon paths

Question 6

During an authorized assessment, what is the most appropriate way to validate a suspected high-impact path?

A. Extract every available credential to maximize evidence

B. Use the least invasive controlled action that confirms the relevant relationship

C. Change production passwords and observe the result

D. Deploy persistence so the path can be retested later

Correct Answer: B. Use the least invasive controlled action that confirms the relevant relationship

Question 7

Which control most directly addresses the risk of privileged sessions on ordinary endpoints?

A. Increasing the default ticket lifetime

B. Using hardened administrative workstations and restricting privileged logons

C. Adding more nested user groups

D. Disabling directory auditing

Correct Answer: B. Using hardened administrative workstations and restricting privileged logons

Question 8

In a zero-trust model, access decisions should primarily depend on which combination?

A. Network location alone

B. Identity, device condition, context, and resource sensitivity

C. User seniority and physical office location only

D. Whether the account has existed for more than one year

Correct Answer: B. Identity, device condition, context, and resource sensitivity

Question 9

Why should a tester recalculate attack paths after remediation?

A. Removing one permission may leave an alternative route to the same objective

B. Directory permissions cannot be changed after an assessment

C. Attack paths are unrelated to identity relationships

D. Remediation always creates a new domain automatically

Correct Answer: A. Removing one permission may leave an alternative route to the same objective

Question 10

Which finding most clearly represents a lifecycle governance weakness?

A. A domain controller uses synchronized time

B. A former employee retains an active privileged account months after departure

C. A user authenticates with a hardware security key

D. A GPO is reviewed before deployment

Correct Answer: B. A former employee retains an active privileged account months after departure