Active Directory Attacks practice questions

The existence of a local administrator group

Why it fails: Every Windows machine has a local administrator group by design. The existence of this group is standard behavior and not inherently a security misconfiguration. Security risk only arises if improper credentials are used or if access controls to this group are poorly managed within the domain infrastructure.

Frequent password rotation for service accounts

Why it fails: Frequent password rotation is a security best practice, not a misconfiguration. It limits the window of opportunity for an attacker if a credential is ever leaked. It does not facilitate domain compromise, and in fact, it serves as a defensive measure against long-term credential persistence and unauthorized access.

Domain user account password complexity requirements

Why it fails: Enforcing password complexity is a standard security control to prevent brute-force attacks. It is not a misconfiguration that leads to domain compromise. Strong password policies are fundamental to protecting Active Directory against unauthorized access and should be implemented as part of a robust organization-wide security posture.

It prevents the account from being used for Kerberoasting

Why it fails: This attribute does not affect Kerberoasting. Kerberoasting relies on the presence of an SPN and is independent of delegation settings. The sensitive/cannot-be-delegated attribute specifically manages how credentials are used during the delegation process, not how the account itself is authenticated against services within the domain infrastructure.

It allows an attacker to perform an AS-REP Roasting attack

Why it fails: AS-REP Roasting is determined by the 'Do not require Kerberos preauthentication' flag. The sensitive/cannot-be-delegated attribute is unrelated to preauthentication requirements. Setting or clearing this flag does not enable or disable the ability to perform an offline password cracking attack using the AS-REP response packets.

It prevents high-privilege credentials from being delegated

Why it fails: The attribute itself is a security feature. The 'risk' is failing to apply it to privileged accounts. If an account is marked as sensitive, its credentials cannot be delegated, which is a defensive measure. The question frames the attribute as a risk, but it is actually a mitigation control.

Kerberoasting the domain controller's machine account.

Why it fails: Kerberoasting requires targeting service accounts with Service Principal Names (SPNs). While machine accounts have SPNs, the pre-Windows 2000 group permissions do not specifically facilitate this; rather, they grant read access to object attributes that can be used to identify targets or extract secret data, not necessarily service tickets.

Exploiting the AD Recycle Bin to recover deleted object secrets.

Why it fails: The AD Recycle Bin is a feature that must be enabled; it is not a direct consequence of the pre-Windows 2000 group membership. While read permissions are necessary to view deleted objects, the primary risk of this group is the broad access to non-deleted, highly sensitive operational attributes.

Executing an AS-REP Roasting attack against all users.

Why it fails: AS-REP Roasting targets accounts that have the 'Do not require Kerberos preauthentication' flag set. This is a user-level account setting and is completely independent of the 'Pre-Windows 2000 Compatible Access' group membership, which focuses on attribute reading permissions rather than pre-authentication settings on individual user objects.

Executing a DCSync attack via Mimikatz to pull credentials.

Why it fails: DCSync is a network-based attack against a domain controller, not a local LSASS extraction technique. It relies on having directory replication rights to request hashes from the NTDS.dit file. It is not performed on a workstation's local LSASS process and requires significantly higher privileges than local admin.

Modifying the SAM database registry hive directly.

Why it fails: The SAM database stores local account hashes, not the credentials of Domain Admins who logged into the machine. While useful for local privilege escalation, the SAM does not contain the tokens or cleartext secrets generated by domain users during their session, making it irrelevant for extracting Domain Admin credentials.

Capturing NTLMv2 hashes via Responder on the local network.

Why it fails: Responder is a network spoofing tool used to intercept NTLMv2 authentication challenges, not a method to extract credentials from a local LSASS process. Capturing hashes over the wire is a separate attack vector that relies on broadcast protocols rather than interacting with the memory of a compromised host.

The GPO is applied to the Domain Controllers container.

Why it fails: While targeting Domain Controllers is a goal, the fact that a GPO is linked there does not automatically imply a misconfiguration. GPOs are frequently applied to Domain Controllers to enforce security hardening. Without specific insecure settings within the GPO itself, its mere location does not indicate an exploitable condition.

The GPO is currently disabled in the Group Policy Management Console.

Why it fails: A disabled GPO does not apply to any computer or user objects. Therefore, it cannot be leveraged for privilege escalation unless the attacker has the ability to re-enable it. A disabled policy is generally considered inert and is not a priority for investigation when looking for active escalation pathways.

Reset the Domain Admin's password directly.

Why it fails: GenericWrite permission does not grant the 'Reset Password' extended right. To perform a password reset, one typically needs 'ForceChangePassword' or 'GenericAll' access. GenericWrite is limited to modifying attributes and does not include the ability to overwrite the existing password directly via AD standard administrative tools.

Add the Domain Admin to a group the attacker controls.

Why it fails: Adding a user to a group is governed by 'WriteMembers' or 'Member' property access, not GenericWrite. GenericWrite is restricted to modifying the attributes of the object itself, such as description, display name, or path, rather than modifying the membership relationship of the object to other groups in the directory.

Modify the 'memberOf' attribute to remove them from Domain Admins.

Why it fails: The 'memberOf' attribute is a back-linked, computed attribute in Active Directory. It cannot be directly modified by a user, even with write access to the object. Changes to group membership must be performed by modifying the 'member' attribute on the group object itself, which requires different permissions than GenericWrite.

Higher privileged accounts have weaker encryption algorithms.

Why it fails: The encryption algorithm used for service tickets (usually RC4 or AES) is determined by the domain's Kerberos configuration and the client's supported types, not the privileges of the account. An attacker will always try to force the use of RC4 if possible, as it is significantly faster to crack offline.

Targeting high privilege accounts forces an immediate domain-wide logout.

Why it fails: Kerberoasting is a passive request for a service ticket; it does not interact with the user's active sessions or force any logouts. Claiming that it forces a domain-wide logout is a misunderstanding of the protocol. It is specifically designed to be a stealthy operation that avoids disrupting services or alerting administrators.

The domain controller will only grant tickets to highly privileged users.

Why it fails: The KDC will grant service tickets to any authenticated domain user for any registered SPN. There is no restriction based on the requester's privilege level. The limitation is simply that the user must be authenticated to the domain to request a ticket for an existing service account in the directory.

Dump the LSASS process memory on a domain controller.

Why it fails: Dumping LSASS memory on a domain controller may reveal credentials of logged-on users, but it does not create a persistent mechanism that survives password changes. It is a one-time extraction that could be repeated only if you maintain access. It does not grant the ability to forge tickets independently of the compromised account.

Configure a scheduled task on a domain controller to run a reverse shell.

Why it fails: A scheduled task on a domain controller can provide persistence, but it is highly visible and easily removed. It also depends on the domain controller being online and the task not being deleted. Unlike a Golden Ticket, it does not leverage the KRBTGT hash and does not survive password changes of the compromised account in a stealthy manner.

Add a new domain user account with Domain Admin privileges.

Why it fails: Adding a new Domain Admin account provides access, but it is easily detected and can be removed by defenders. Moreover, if the original compromised account's password changes, the new account remains, but it is a separate account that might be discovered and disabled. It does not provide the stealth and longevity of a Golden Ticket.

net group "Domain Computers" /domain

Why it fails: This command lists members of the Domain Computers group, which includes all workstations and servers by default, but it does not reveal delegation settings. It provides no information about unconstrained delegation and is far too broad to be useful for this specific enumeration goal. Running it would not help identify vulnerable hosts and may generate unnecessary noise.

dsquery computer -name * -delegation

Why it fails: The dsquery computer command does not have a -delegation switch; this option is fabricated. While dsquery can retrieve computer objects, filtering by delegation requires using the -attr or LDAP filters, and even then it is less straightforward than the PowerShell approach. It would fail or produce an error, making it an ineffective choice here.

nltest /dclist:domain

Why it fails: nltest /dclist lists domain controllers in the specified domain, not computers with unconstrained delegation. It provides no delegation-related information and is used for domain trust and DC discovery. This command would not help identify delegation misconfigurations and is irrelevant to the scenario.

Run a full TCP port scan against all domain subnets to identify open SMB ports, then attempt authentication to each.

Why it fails: A full TCP port scan across all subnets generates significant traffic and is easily detected by network monitoring tools. While it would identify systems with SMB open, it does not directly reveal local administrator rights for jsmith and is unnecessarily noisy. This approach fails to meet the objective of minimizing network noise and efficiently targeting systems where jsmith has elevated privileges.

Query the domain for computer objects where jsmith has been granted administrative rights via Group Policy Preferences or restricted groups.

Why it fails: Group Policy Preferences or Restricted Groups can grant local admin rights, but these settings are stored in SYSVOL and are not directly linked to user accounts in a way that is easily queryable per user. This method would require parsing GPOs and may miss rights granted through other mechanisms like direct ACLs on computer objects. It is not a comprehensive or efficient way to identify all systems where jsmith is local admin.

Use PowerView's Invoke-EnumerateLocalAdmin to query each computer object's local Administrators group via remote registry or SMB.

Why it fails: Invoke-EnumerateLocalAdmin in PowerView attempts to enumerate local administrators on remote systems, but it relies on remote registry or SMB access and may fail if those services are restricted. It also generates authentication attempts that could be logged. While useful, it is not the most efficient or stealthy method compared to querying directory objects directly for access control information.

Execute a resource-based constrained delegation attack by modifying the target user's msDS-AllowedToActOnBehalfOfOtherIdentity attribute.

Why it fails: Resource-based constrained delegation is configured on computer objects via msDS-AllowedToActOnBehalfOfOtherIdentity, not user objects, and requires control of a machine account. Applying it to a user object does not establish the delegation relationship needed, so this technique does not match the target of your GenericAll ACE.

Use the GenericAll permission to perform a shadow credentials attack, generating a certificate for the target and authenticating with it via PKINIT.

Why it fails: Shadow credentials abuse the msDS-KeyCredentialLink attribute to add a rogue key credential, which does allow authentication as the target. However it requires write access to that specific attribute, and GenericAll over a user object is more directly exploited by resetting the password, which is simpler and does not depend on AD CS being present.

Perform a targeted Kerberoasting request against the target user, crack the resulting ticket, then authenticate as that user.

Why it fails: Targeted Kerberoasting requires the ability to write a Service Principal Name to the target account, which GenericAll does permit, but it only yields a crackable ticket. If the account has a strong password the crack fails and you gain nothing, so it is not the reliable path the scenario needs.

The service account is restricted to specific logon hours or workstations.

Why it fails: While logon restrictions can cause authentication failures, they typically result in a different error and are less common than other causes. Moreover, the scenario states the account has local admin rights, but does not mention such restrictions. This option is plausible but not the most likely without additional evidence.

The target system has SMB signing enabled, preventing NTLM relay.

Why it fails: SMB signing prevents relay attacks, not Pass-the-Hash. Pass-the-Hash authenticates directly using the hash and does not rely on relaying. SMB signing would not cause an 'Access Denied' error in this context; it would only block man-in-the-middle relay attempts. Therefore, this is not the reason for the failure.

The target system enforces NTLMv2 and the hash is from an NTLMv1 response.

Why it fails: Pass-the-Hash works with both NTLMv1 and NTLMv2 hashes, as the hash itself is used directly for authentication. The version of NTLM used during the original authentication does not affect the ability to pass the hash. This option misrepresents how PtH operates and is therefore incorrect.

Use Responder to poison LLMNR on the target subnet and relay the service account's authentication to the member server.

Why it fails: Responder captures and poisons name resolution to harvest credentials from hosts on the network, but you already possess the hash and need to use it, not capture more. Relaying also requires a victim authentication attempt and is unnecessary here where direct hash-based authentication is available.

Use Impacket's smbclient.py with the -hashes flag to authenticate over SMB and obtain a shell on the target server.

Why it fails: smbclient.py with -hashes does authenticate using the NT hash, but it only provides file share access and command execution primitives, not an interactive logon session on the host. It does not satisfy the goal of obtaining a full interactive shell on the member server in the way the scenario requires.

Use Mimikatz to perform a DCSync against the domain controller and retrieve the service account's cleartext password.

Why it fails: DCSync requires replication rights such as Replicating Directory Changes All, which a service account with local admin rights does not hold by default. Even if it succeeded it would return the NT hash, not the cleartext, so it does not solve the access problem and is far noisier.

Use CrackMapExec with the --hash option to spray the hash across the network and execute commands on successful logins.

Why it fails: CrackMapExec supports Pass-the-Hash with the --hash option, but it is primarily used for mass authentication attempts and command execution across many targets. While it could work, it is not as direct as using Mimikatz to inject the hash into a session for interactive command execution. The scenario asks for least effort to execute commands on specific servers, and CrackMapExec may be overkill or less precise.

Use Hashcat with the -m 1000 mode to crack the NTLM hash and recover the plaintext password.

Why it fails: Cracking the NTLM hash with Hashcat may eventually reveal the plaintext password, but it is time-consuming and not guaranteed, especially for complex passwords. The scenario requires immediate authentication and command execution; cracking is inefficient and may fail. Pass-the-Hash avoids the need to crack, making this option less suitable.

Use Responder to capture additional authentication attempts and relay them to the target servers.

Why it fails: Responder is used to capture hashes via network poisoning, not to authenticate with a known hash. It does not directly allow using a captured NTLM hash to authenticate to servers. This approach would require additional steps like relay, which is not guaranteed to work if SMB signing is enabled. It does not meet the requirement of using the obtained hash for authentication.

Get-DomainUser -TrustedToAuth

Why it fails: The -TrustedToAuth switch filters accounts with the TRUSTED_TO_AUTH_FOR_DELEGATION flag, which indicates protocol transition for constrained delegation, not unconstrained delegation. It is useful for finding constrained delegation setups, but it does not identify the unconstrained computers the scenario asks about.

Get-DomainTrustMapping

Why it fails: Get-DomainTrustMapping enumerates trust relationships between the current domain and other domains or forests. While useful for mapping lateral movement paths across trusts, it does not inspect userAccountControl flags and therefore cannot identify accounts with unconstrained delegation enabled.

Get-DomainGPO -ComputerIdentity dc01

Why it fails: This cmdlet retrieves the Group Policy Objects applied to a specified computer, which is useful for auditing policy settings and GPO-based attack paths. It has no relationship to delegation flags, so it will not reveal which accounts are trusted for unconstrained delegation.

Configure constrained delegation on a computer you control to impersonate a Domain Admin to a service.

Why it fails: While constrained delegation can be abused, the SeEnableDelegationPrivilege is not required to configure it on a computer you already control; that typically requires write access to the object's msDS-AllowedToDelegateTo attribute. This privilege is specifically about enabling delegation, not setting up the delegation itself. This option is plausible but not the most direct abuse.

Add your user to the Domain Admins group using the GPO.

Why it fails: The SeEnableDelegationPrivilege does not allow modifying group memberships. It specifically allows configuring delegation settings on user and computer objects. Adding to Domain Admins would require other privileges like WriteDacl or WriteMember. This option misinterprets the privilege's scope.

Modify the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on a target computer to allow your account to impersonate any user.

Why it fails: This attribute is used for resource-based constrained delegation (RBCD). Modifying it requires write access to the target object, not SeEnableDelegationPrivilege. RBCD abuse is a separate technique. This option confuses the privileges needed for RBCD with those for enabling delegation.

Rubeus kerberoast

Why it fails: Rubeus is a C# tool that can perform Kerberoasting, but it is not a command-line tool in the same sense as PowerShell functions; it is a standalone executable. While it is commonly used, the question asks for a tool specifically designed for this purpose in OSCP-like environments, where PowerShell scripts like Invoke-Kerberoast are more prevalent. Rubeus is also valid but less likely to be the expected answer in a pure OSCP context.

setspn -T domain -Q */*

Why it fails: setspn is a built-in Windows tool that queries SPNs, but it does not perform Kerberoasting. It can help identify accounts with SPNs, but it does not request or extract Kerberos tickets. This option is a enumeration step, not the actual attack tool.

Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName

Why it fails: This cmdlet lists users with SPNs, which are potential Kerberoasting targets, but it does not extract the ticket hashes. It only identifies them; additional steps are needed to request and extract the hashes. While useful for enumeration, it is not the tool specifically designed to perform Kerberoasting itself.

Kerberoasting the computer account password hash

Why it fails: Kerberoasting targets service accounts with service principal names registered. The ms-MCS-AdmPwd attribute is specific to LAPS, which manages local administrator passwords for domain-joined machines. Kerberoasting requires requesting a service ticket for an account with an SPN, which is a fundamentally different mechanism than reading LAPS password attributes.

Exploiting the GPO to modify the Domain Admins group

Why it fails: Modifying the Domain Admins group requires permissions to write to Group Policy Objects or the group membership itself. Reading the ms-MCS-AdmPwd attribute only provides the current local administrator password for a specific host, not the permissions necessary to alter enterprise-wide security configurations or administrative group memberships.

Performing an AS-REP Roasting attack on the machine

Why it fails: AS-REP Roasting targets user accounts where the 'Do not require Kerberos preauthentication' flag is set. This allows an attacker to request a TGT without providing the user's password. LAPS attribute access is unrelated to preauthentication flags and does not involve the Kerberos AS-REQ/AS-REP exchange process for ticket requests.

Mimikatz

Why it fails: Mimikatz is an post-exploitation tool primarily used for credential dumping, such as extracting NTLM hashes or Kerberos tickets from memory. While powerful, it is not used for mapping environment-wide attack paths or collecting the graph data required to visualize relationships between Active Directory entities for path analysis.

Responder

Why it fails: Responder is a network-level tool used for poisoning protocols like LLMNR, NBT-NS, and MDNS to capture NTLMv2 hashes. It is used for credential harvesting and relay attacks, not for mapping the structure of an Active Directory environment or generating graph-based data for long-term path analysis.

PowerSploit

Why it fails: PowerSploit is a framework of PowerShell modules used for various post-exploitation tasks, such as process injection and local enumeration. While it includes many useful scripts, it is not the standard dedicated tool for collecting the specific graph-based data required to populate BloodHound's analysis engine.

Kerberoasting

Why it fails: Kerberoasting is an initial access or privilege escalation technique used to extract password hashes for offline cracking. It is not a persistence mechanism, as it does not inherently provide a way to regain access to the domain after the current session ends or if the account password is changed.

LLMNR Poisoning

Why it fails: LLMNR poisoning is a technique used to capture network traffic and NTLMv2 hashes. It relies on the local network broadcast environment and is an opportunistic attack vector. It cannot be used to establish long-term persistence in Active Directory, as it does not grant the attacker continuous, reliable authentication capabilities.