Domain Escalation and Persistence practice questions

The entry only triggers when a specific user logs into the machine.

Why it fails: Entries under HKLM are global and execute for any user session initiated on the host. HKCU entries are the ones limited to a specific user profile. Misidentifying the scope of registry persistence leads to incorrect assumptions about the breadth of the established backdoor on the target system.

The service will only execute if the user has administrative privileges.

Why it fails: Registry run keys execute programs regardless of the user's privilege level, provided the program itself is accessible. If the program requires elevated rights, it may fail to run or prompt for UAC, but the execution attempt is not inherently restricted to administrators by the registry key mechanism.

The key is invalid because it uses double backslashes in the path.

Why it fails: Double backslashes are the standard representation for directory separators within the Windows registry environment. They do not invalidate the entry, nor do they prevent the operating system from correctly interpreting the path. The registry editor displays them this way to escape special characters correctly in the underlying data.

The service is disabled, so it poses no threat.

Why it fails: The exhibit explicitly shows that the start type is 'AUTO_START'. This means the service is configured to launch automatically when the system boots, making it a viable target for persistence if an attacker can manipulate the service's configuration or the binary it is associated with in the registry.

The binary path is invalid and will cause a crash.

Why it fails: The path 'C:\Windows\System32\svchost.exe' is a standard, valid Windows system binary. It will not cause a system crash. The path is legitimate; the danger lies in the service configuration and the potential for abuse of the LocalSystem account context under which the service is configured to execute.

The service name 'HiddenService' is illegal in Windows.

Why it fails: Windows does not restrict the naming of services in this manner. 'HiddenService' is a perfectly valid service name. The name itself does not prevent the service from running or being managed by the Service Control Manager, and it does not invalidate the service's configuration or its security posture.

Install a Windows service that runs a custom binary as Local System.

Why it fails: Installing a service typically involves registry modifications under HKLM\SYSTEM\CurrentControlSet\Services, which violates the constraint of not modifying the registry. Service creation is also logged and the binary on disk can be detected by antivirus. While it provides persistence, it does not satisfy the scenario's specific restrictions.

Place a shortcut in the user's Startup folder that launches a reverse shell.

Why it fails: Startup folder persistence is user-specific and only triggers when that user logs on. It does not require registry changes, but it is easily discovered by examining the Startup folder and is not stealthy. It also fails to provide system-wide persistence across reboots if the user does not log in, and it may not survive if the user profile is cleaned.

Create a new local user account and add it to the Administrators group.

Why it fails: Creating a local admin account is a common persistence technique, but it is highly visible in local user management and event logs. It does not meet the requirement to avoid registry or scheduled task modifications, and it is easily detected by account auditing. It also does not provide stealth, as new accounts are flagged by many security tools.

Create a scheduled task on the domain controller that runs a reverse shell every hour.

Why it fails: A scheduled task on a domain controller is a file and registry artifact that is easily detected by security audits. It is not stealthy and can be found by examining the Task Scheduler library. While it survives reboots, it fails the requirement to remain undetected. Additionally, running a reverse shell every hour may trigger network-based alerts.

Create a new domain admin account with a name similar to a legitimate service account.

Why it fails: Creating a new domain admin account is a common technique, but it is not stealthy. Account creation and group membership changes are logged on domain controllers and easily caught by security audits. It also does not survive a thorough review, as the account will appear in user lists. It fails the requirement to remain undetected by standard security audits.

Modify the ACL of the Domain Admins group to grant full control to a controlled user account.

Why it fails: Modifying the Domain Admins ACL is a persistent change in Active Directory. While it may survive reboots, it is detectable by ACL monitoring tools and directory audits. It is not stealthy because it alters the permissions of a critical group, which is often monitored. It also requires the controlled account to remain enabled, which is a red flag during security reviews.

Create a new user and set their shell to /bin/bash, then add them to the 'wheel' group.

Why it fails: Adding to the 'wheel' group may grant sudo privileges depending on the distribution, but it is not guaranteed and is more visible. It also does not directly grant root privileges without sudo configuration. The UID 0 method is more direct and stealthy.

Create a new user and add them to the sudoers file with NOPASSWD: ALL.

Why it fails: Adding a user to sudoers with NOPASSWD: ALL grants root privileges via sudo, but it is more visible because the sudoers file is often monitored. It also requires the user to run sudo, which may be logged. The UID 0 method is stealthier as it directly creates a root-equivalent account.

Modify the root user's password and store it for later use.

Why it fails: Changing the root password could disrupt legitimate administrative access and is highly likely to be noticed. It is not stealthy and may trigger alerts. Additionally, it does not create a separate backdoor; it alters the existing root account.

Create a new scheduled task that runs at logon of any user, with the action set to your payload.

Why it fails: Scheduled tasks are a common persistence mechanism and are frequently audited. Creating a new task with a logon trigger may be flagged by security tools, especially if the task runs with high privileges. While it achieves logon-triggered execution, it is not the stealthiest option and may be easily discovered by defenders reviewing scheduled tasks.

Modify the ImagePath value of an existing service to point to your payload.

Why it fails: Changing a service's ImagePath requires restarting the service, which may cause disruption and generate events. It does not trigger on user logon, so it fails to execute when any user logs on. Additionally, service modifications are often monitored by security tools, increasing detection risk. This method does not meet the stealth and logon-triggered execution requirements.

Add a registry value under HKCU\Software\Microsoft\Windows\CurrentVersion\Run that points to your payload.

Why it fails: The Run key under HKCU only executes when the specific user logs on, not any user. It also requires you to have write access to that user's registry hive, which may not be available if you are operating as a different user. This method does not meet the requirement of executing for any user logon and is less stealthy than other options.

Modify the Image File Execution Options registry key for a system process.

Why it fails: Modifying Image File Execution Options (IFEO) for a system process typically requires administrative privileges because it involves changing registry keys under HKLM. Additionally, IFEO is used for debugging and can be abused for persistence, but it is not a user-level technique and often requires elevation. Thus, it is not appropriate for a non-admin scenario.

Create a new Windows service that runs a malicious executable.

Why it fails: Creating a new Windows service requires administrative privileges. Since you do not have admin rights, this technique is not feasible. Services run with high privileges and are managed by the Service Control Manager, which restricts creation to administrators. Thus, this option is not appropriate for a non-admin persistence scenario.

Schedule a task using schtasks with the /RU SYSTEM flag.

Why it fails: Scheduling a task to run as SYSTEM requires administrative privileges. The /RU SYSTEM flag specifies the task runs under the SYSTEM account, which is a highly privileged context. A non-admin user cannot create such a task. Therefore, this technique is not viable without admin rights and does not meet the requirement.

A script placed in /etc/cron.d/ with a @reboot schedule.

Why it fails: While /etc/cron.d/ is a system-wide cron directory, using @reboot there will execute the job at cron daemon startup, which typically occurs at system boot. However, this is not the most reliable method because some cron implementations may not support @reboot, and the directory is intended for package-managed cron files. It is less stealthy and may be overwritten.

A user-specific crontab entry created with 'crontab -e'.

Why it fails: User-specific crontabs are stored in /var/spool/cron/crontabs/ and are executed according to the schedule defined by the user. They do not have a special @reboot behavior that runs at system startup unless explicitly specified. Moreover, they run with the user's privileges and only when the cron daemon is running. This does not guarantee execution at startup independent of login.

An entry in /etc/rc.local.

Why it fails: /etc/rc.local is a script that runs at the end of the boot process on some Linux distributions, but it is deprecated in many modern systems using systemd. It requires execution permissions and is often not present by default. Relying on it is not portable and may not work on all systems, making it less reliable for persistence.

Add a command to the user's ~/.bashrc file.

Why it fails: The .bashrc file is executed for interactive non-login shells, but SSH logins typically start a login shell that reads .bash_profile or .profile instead. Therefore, a command in .bashrc may not execute on SSH login, depending on shell configuration. It also only runs when a new interactive shell is started, not necessarily at login, making it unreliable for this scenario.

Add a command to /etc/profile.d/ script.

Why it fails: Scripts in /etc/profile.d/ are executed for all users on login shells, making it system-wide and easily noticed by administrators. It also affects all users, not just the specific user, and may be monitored for changes. This fails the requirement to avoid modifying system-wide files and to target a specific user, increasing the risk of detection.

Create a systemd service that runs on user login.

Why it fails: Systemd user services are started when the user's systemd instance starts, which typically happens at the first login and persists. However, creating a new service requires writing to system directories or user configuration directories that may be monitored. It also does not guarantee execution on every SSH login if the user session persists. This method is less stealthy and less precise for triggering on each SSH login.

Add your own SSH public key to the domain administrator's authorized_keys file on the domain controller.

Why it fails: Domain controllers typically do not run SSH services by default, and adding an SSH key would require enabling SSH, which is not standard. This method is more applicable to Linux systems. On a Windows domain controller, this is unlikely to work unless SSH is installed and configured, and it would not provide domain-level persistence. It fails to meet the scenario's requirements.

Use Mimikatz to inject a golden ticket into the KRBTGT account.

Why it fails: A golden ticket involves compromising the KRBTGT account hash and forging TGTs, providing persistent domain access until the KRBTGT password is changed twice. However, it requires obtaining the KRBTGT hash, which is a highly privileged action and may be detected. It is not a stealthy persistence method by itself, as it relies on a single hash that can be reset. It also does not survive a KRBTGT password reset, making it less reliable for long-term persistence.

Create a new domain admin account with a similar name to an existing service account.

Why it fails: Creating a new domain admin account is a common persistence method, but it is not stealthy. Domain admin account creation generates events that are often monitored, and a new account with a similar name may be flagged by security tools. It also does not survive password changes of the initial account, as it is a separate account, but the requirement is to maintain access despite password changes to the initial account, which this does not address directly.

DCSync to extract the user's password hash and use it for pass-the-hash.

Why it fails: DCSync requires domain administrator or equivalent privileges to replicate directory data. If you have such privileges, you could extract the hash, but pass-the-hash only works until the password is changed, as the hash becomes invalid. It does not provide persistence beyond a password change. Additionally, DCSync is a high-privilege action that may be detected. This does not meet the requirement of surviving password changes.

Add a backdoor user account to the domain admins group.

Why it fails: Adding a user to the Domain Admins group creates a new privileged account, which is easily detected by security monitoring. It does not survive password changes of the compromised user, as it is a separate account. It also requires domain admin privileges to perform. This method is not stealthy and does not meet the requirement of re-authenticating as the compromised user.

Deploy a Skeleton Key on the domain controller.

Why it fails: Skeleton Key patches LSASS on a domain controller to accept a master password for any account. It provides persistence that survives password changes, but it is not a domain infrastructure technique in the sense of leveraging AD protocols; it is a memory patch on a single DC. It also requires domain controller access, which may not be available from a workstation. This does not best achieve the goal from a workstation compromise.

Overwrite the existing service executable with a custom payload.

Why it fails: Overwriting the actual binary requires administrative permissions that you do not yet possess. If you had permissions to modify the existing binary, you would already have achieved execution, rendering the unquoted path vulnerability irrelevant. This action is usually blocked by standard NTFS access control lists on system directories.

Modify the service configuration using the sc config command.

Why it fails: Changing the service configuration via sc config requires elevated administrative privileges. Since the goal is to escalate privileges, you cannot rely on commands that already require the level of access you are attempting to obtain. This approach is ineffective for a standard user account seeking privilege escalation.

Inject a DLL into the running service process memory space.

Why it fails: Process injection via DLL injection typically requires administrative rights or SeDebugPrivilege to attach to a high-privilege service process. While effective for persistence or credential dumping, it does not leverage the unquoted service path vulnerability itself and is generally restricted for unprivileged users on modern Windows operating systems.

Modifying the /etc/shadow file to grant root access.

Why it fails: Modifying /etc/shadow is a method for privilege escalation through credential manipulation, not a persistence mechanism related to cron jobs. While effective for gaining access, it does not involve the time-based scheduling functionality provided by the cron daemon and is highly visible to integrity monitoring systems.

Replacing the bash shell binary with a malicious version.

Why it fails: Replacing the system shell is an extreme persistence technique that risks system instability. It is not a method involving cron jobs, which are designed for task scheduling. This approach is easily detected by file integrity monitoring tools that check the checksums of critical system binaries regularly.

Setting a boot-time delay in the global /etc/environment file.

Why it fails: /etc/environment is used for setting system-wide environment variables, not for scheduling recurring tasks. Setting a delay here would not achieve persistence through cron, as it does not control the execution of processes or scripts over time in the manner that the cron daemon is configured to do.

It forces the file to run within a restricted sandbox environment.

Why it fails: SUID does not provide sandboxing; rather, it elevates the execution context. Sandboxing is a security control used to isolate processes, whereas SUID is a legacy permission mechanism that explicitly grants higher privileges to the process during execution, which is the opposite of the restricted goal of sandboxing.

It enables the file to be readable by all users on the system.

Why it fails: SUID affects execution privileges, not file system read permissions. Read permissions are governed by the standard rwx bits for owner, group, and others. The SUID bit specifically modifies the process's effective user ID upon execution and has no direct impact on the file's static read permission settings.

It automatically encrypts the file contents at rest.

Why it fails: The SUID bit is a permission attribute, not a cryptographic control. It is entirely unrelated to data encryption or the security of file contents while stored on disk. Encryption is handled by separate filesystem or application-level tools, and SUID remains strictly a function of the Linux permission model.

Adding a startup shortcut to the All Users Startup folder.

Why it fails: The Startup folder is a well-documented and frequently monitored location. It is considered an entry-level persistence mechanism that is easily detected by antivirus software and endpoint detection and response (EDR) solutions. It is not considered stealthy for a professional penetration test or an advanced threat actor.

Modifying the existing service binary to include a backdoor.

Why it fails: Modifying existing system binaries is highly risky, as it triggers file integrity monitoring (FIM) and is likely to be detected by EDR solutions. Furthermore, it requires administrative privileges that the attacker might not have, making this method both loud and potentially difficult to execute during the escalation phase.

Running a scheduled task with a visible command prompt window.

Why it fails: Scheduled tasks that launch visible windows are immediately obvious to the system user. Stealth is a key component of effective persistence, and any method that interferes with the user experience or is clearly visible is likely to be investigated and removed by the user or security personnel.

Attempt to restart the system to reset privileges.

Why it fails: Restarting the system is counterproductive and likely to cause a loss of the current session. It does not reset privileges in a way that helps the tester; instead, it alerts administrators and potentially removes the temporary access that the tester has already achieved on the compromised host system.

Disable the privilege to ensure system stability.

Why it fails: A penetration tester's objective is to demonstrate risk, not to improve system stability or remediate vulnerabilities. Disabling the privilege would prevent further testing and would not align with the goal of identifying exploitable pathways for privilege escalation within the scope of the assigned security assessment engagement.

Install a rootkit to hide the enabled privilege.

Why it fails: Installing a rootkit is generally out of scope for most professional penetration tests and could lead to system instability or detection. The goal is to document the risk associated with the enabled SeDebugPrivilege, not to modify the system in a way that risks permanent damage or excessive noise.

Configuring a new user account with no password.

Why it fails: Creating a new user account is not a privilege escalation technique; it is a persistence technique. While it provides access, it does not inherently escalate the user's current privileges. Furthermore, adding new accounts is highly visible to administrators and is likely to be detected by standard auditing tools.

Renaming the /etc/passwd file to /etc/shadow.

Why it fails: Renaming core system files will cause immediate system failure and is not a valid technique for privilege escalation. This action would disrupt system services and potentially lock out all users, including the root user, making it destructive rather than a useful method for gaining elevated control during a test.

Gaining initial access to a target network via phishing.

Why it fails: Initial access is the first stage where an attacker gains a foothold in the network. This is separate from persistence, which occurs after the initial compromise to ensure the attacker does not lose access once the session is terminated or the target system is rebooted by the user.

Exfiltrating sensitive data to an external server.

Why it fails: Exfiltration is the act of removing data from the target network. This is usually the final stage of an attack and is distinct from persistence, which focuses on maintaining access to the target rather than the movement of data out of the environment or the stealing of information.

Encrypting the system for ransomware purposes.

Why it fails: Ransomware is an impact-oriented action that disrupts system availability. Persistence is about long-term access, whereas ransomware aims to cause damage or demand payment. While ransomware might use persistence to stay active, the two are distinct concepts within the kill chain, and one is not synonymous with the other.

The account may trigger an automated system update.

Why it fails: Backdoor accounts do not influence system update processes. Updates are managed by system services or administrators and are independent of user account existence. The danger is related to unauthorized access and persistence, not the operational behavior of the system's patching mechanisms or the management of system software updates.

The system performance will degrade due to the account.

Why it fails: A single user account has negligible impact on system performance. The primary concern is security, not the system's resource utilization. Identifying this as a performance issue misunderstands the nature of the risk, which is centered on unauthorized access rather than the consumption of CPU or memory by the OS.

The account automatically encrypts data in the directory.

Why it fails: Standard user accounts do not possess inherent encryption capabilities. This is a functional misunderstanding of how user accounts interact with the operating system and data security. The risk associated with a backdoor account is access control and unauthorized entry, not the automatic transformation of data via cryptographic means.

Increased usage of the CPU by the system kernel.

Why it fails: High kernel CPU usage is often related to driver issues, hardware problems, or system-level bottlenecks. While some malware might cause performance issues, it is not a primary indicator of persistence. More reliable indicators are configuration changes that ensure code execution upon reboot, rather than general performance-based telemetry data.

Changes to the system's desktop wallpaper.

Why it fails: Changing the wallpaper is a trivial, non-persistent action that is often performed by pranksters. It does not provide any mechanism for maintaining access across reboots and is not considered a reliable indicator of a serious security compromise or persistent threat actor presence within a target environment.

A high number of failed login attempts in the event log.

Why it fails: Failed login attempts are indicative of a brute-force or password-spraying attack, not persistence. Persistence is about maintaining access once you are already on the system. While brute force is part of the initial access phase, it is not a direct marker of successfully established persistence on the host.