Endpoint Security practice questions

Disable the Windows Remote Management (WinRM) service globally.

Why it fails: Disabling WinRM globally breaks legitimate administrative workflows and automation scripts. While it stops lateral movement, it is too disruptive for a production environment. Security controls must balance risk reduction with operational functionality by implementing targeted restrictions rather than nuclear options that stop all remote management.

Enable Windows Defender Credential Guard to isolate LSASS.

Why it fails: Credential Guard protects against credential theft by isolating secrets in a virtualized container. While it prevents attackers from dumping memory to steal hashes, it does not restrict the network-level access paths required for PowerShell Remoting. It is a defense-in-depth measure, not a control for movement restriction.

Implement AppLocker in 'Audit Only' mode to track PowerShell usage.

Why it fails: AppLocker in 'Audit Only' mode does not actively block execution; it merely logs activity for review. While useful for visibility, it fails to prevent unauthorized lateral movement as it does not enforce a deny policy. Security controls must be set to 'Enforce' mode to effectively mitigate threats.

File-based signature matching against a global cloud database.

Why it fails: Signature-based detection is a function of traditional antivirus and is primarily designed for prevention rather than post-compromise investigation. While EDR uses signatures, its defining characteristic is behavioral telemetry, which is necessary for detecting non-malware-based attacks or zero-day threats that lack pre-existing signatures in the database.

Real-time blocking of known malicious websites via DNS filtering.

Why it fails: DNS filtering is a preventative control typically managed at the network perimeter or via endpoint security agents to block access to malicious domains. It aims to stop the initial delivery or C2 connection, rather than providing the visibility and forensic data required for deep-dive post-compromise investigation.

Enforcement of disk encryption policies via MDM integration.

Why it fails: Disk encryption is a data-at-rest protection control designed to prevent unauthorized physical access to sensitive data. It does not monitor endpoint behavior or provide forensic telemetry for investigation. While critical for overall endpoint security, it is not a primary component of EDR-based post-compromise detection and analysis workflows.

Enforcing complex passwords for local administrator accounts.

Why it fails: Complex passwords do not prevent Pass-the-Hash attacks, because the attack uses the hash of the password, not the password itself. If an attacker extracts the NTLM hash from LSASS memory, they can use it regardless of how complex or long the original password was. Password policy is insufficient.

Increasing the frequency of password rotation for all users.

Why it fails: Password rotation does not mitigate PtH attacks. The attack relies on the hash currently resident in memory. Even if the password is rotated, the hash for the previous password may still exist in memory, or the new hash can be harvested just as easily, providing no real protection.

Installing an antivirus agent on all workstations.

Why it fails: Standard antivirus agents are not typically configured to prevent Pass-the-Hash, which is a legitimate authentication mechanism being abused. While some EDR tools can detect the behavior, standard AV does not address the underlying architectural vulnerability of NTLM or the storage of credentials in cleartext or weak formats.

Windows Defender Application Control (WDAC) logs

Why it fails: WDAC enforces code integrity policies and logs blocked executables, but it does not provide visibility into memory-resident code or process injection. If the malware bypassed WDAC or used a trusted binary, no WDAC event would be generated. WDAC is a preventive control, not a forensic tool for analyzing in-memory threats.

Windows Event Logs, specifically Security event ID 4688 (Process Creation)

Why it fails: Security event ID 4688 logs process creation, including the image name and command line, but it does not capture in-memory code injection or the contents of a process's memory space. Fileless malware that injects into a running process will not generate a new process creation event for the injected code, so this log alone cannot reveal the malicious payload or its origin.

Windows Performance Recorder (WPR) with the CPU usage profile

Why it fails: WPR captures performance traces such as CPU and disk usage, which can show anomalous resource consumption but lacks the granularity to identify injected code or its source. It is not designed for security forensics and does not record memory regions, thread stacks, or module loads associated with process injection.

seccomp filters with a whitelist of allowed system calls

Why it fails: seccomp restricts the system calls a process can make, reducing the attack surface, but it operates after a binary has started and does not check signatures. It cannot distinguish between signed and unsigned binaries for privilege escalation. seccomp is a sandboxing tool, not an integrity verification mechanism, so it fails to meet the stated goal.

SELinux in enforcing mode with a strict policy

Why it fails: SELinux provides mandatory access control based on labels and policies, but it does not natively verify digital signatures of binaries for privilege escalation. While SELinux can restrict what a process can do, it does not enforce that only signed binaries can execute with elevated privileges. Achieving that requires a separate integrity mechanism, so SELinux alone is insufficient for this requirement.

AppArmor with profile-based confinement

Why it fails: AppArmor confines programs to a limited set of resources based on profiles, but it does not validate digital signatures of executables. It can prevent a program from performing certain actions, but it cannot enforce that only signed binaries gain elevated privileges. The requirement for signature-based privilege control is not addressed by AppArmor's path-based confinement model.

/etc/crontab

Why it fails: /etc/crontab is the system-wide crontab file, but it typically includes a user field and is not where per-user cron jobs are stored. While an attacker could modify it, the question specifies a job that runs every minute, which is more commonly placed in a user's crontab. Examining /etc/crontab is important but not the first place for a per-minute user job.

/etc/cron.d/

Why it fails: /etc/cron.d/ contains system cron jobs with a format similar to /etc/crontab, including a user field. While attackers may place jobs here, it is less common for per-minute persistence because these files are typically managed by packages and more visible. The root user's crontab is a more direct and stealthy location for a malicious job. Thus, it is not the first place to check.

/etc/cron.hourly/

Why it fails: /etc/cron.hourly/ contains scripts executed hourly by run-parts, not per-minute jobs. A job running every minute cannot be configured here. Attackers seeking frequent execution would not use this directory. Therefore, it is not the correct location to find a per-minute cron job.

Windows Defender Firewall with outbound rules blocking unknown applications

Why it fails: Windows Defender Firewall filters network traffic based on ports, protocols, and programs, but it does not prevent execution of local unapproved binaries or scripts. A malicious executable that does not communicate over the network, or that uses an allowed port, would still run. Firewall rules are a network control, not an application execution control, so they do not satisfy the endpoint hardening requirement.

Windows Defender Application Control (WDAC) in audit mode

Why it fails: WDAC is a strong application control mechanism, but running it in audit mode only logs what would have been blocked; it does not actually prevent unapproved code from executing. The scenario requires enforcement, not just visibility. Audit mode is typically used during a pilot to identify compatibility issues before switching to enforced mode, so it would fail to meet the stated hardening goal here.

Software Restriction Policies (SRP) with a disallowed-by-default rule

Why it fails: SRP can block unapproved executables, but it is a legacy feature that is not supported on all modern Windows editions and lacks the publisher-based rule flexibility of AppLocker. It also does not natively handle script and packaged app control as cleanly. While it might block some binaries, it is not the best fit for a fleet that must run approved signed third-party software with minimal disruption.

The application will run normally because AppData is a standard location.

Why it fails: The policy contains an explicit 'Deny' rule for the AppData path. In 'Enforce' mode, the security agent will evaluate this rule before allowing execution. Since the rule is a hard block, the application will be prevented from running, regardless of whether it is legitimate or malicious software.

The application will run, but the activity will be logged for review.

Why it fails: The 'Mode' field is set to 'Enforce', meaning the security agent will actively block disallowed actions. If the mode were set to 'Audit', the activity would be logged but allowed. Since 'Enforce' is active, the agent must block the application rather than just recording the event for later review.

The system will automatically move the application to Program Files.

Why it fails: Security agents do not perform automated file relocation as part of their execution control policies. They perform either 'Allow' or 'Deny' evaluations based on predefined rules. Attempting to move files would require elevated privileges and a complex file system driver, which is outside the scope of execution control.

Disabling local administrator accounts for standard users.

Why it fails: While removing local admin rights is a critical security best practice, it does not prevent a user from executing malicious code within their own user space. An attacker could still run malware that does not require elevated privileges, such as file-less scripts or standard user-level backdoors.

Enabling real-time scanning in antivirus software.

Why it fails: Antivirus software relies on signatures or heuristics to detect malware. It is inherently reactive and can be bypassed by new or obfuscated threats. While necessary for general defense, it cannot provide the same level of assurance as an allowlisting policy, which restricts execution to known-good binaries only.

Configuring the firewall to block all inbound traffic.

Why it fails: Blocking inbound traffic prevents external attackers from reaching the machine, but it does not protect against malware introduced via phishing, physical media, or browser-based attacks. Execution control is a local endpoint issue that requires specific software-level restriction policies, not just network-level filtering to block unsolicited connections.

Disabling all network connections to the endpoint.

Why it fails: Disabling all network connections makes the device non-functional in a modern business environment. While it stops ransomware from communicating, it is not a viable security strategy. Effective defense-in-depth relies on allowing necessary business traffic while inspecting and controlling that traffic, not simply severing all connectivity to the network.

Enabling guest access for easier file sharing across departments.

Why it fails: Enabling guest access increases the attack surface and allows unauthorized users to access resources. This is the opposite of good security hygiene, as it provides a path for ransomware to traverse the network more easily. Security controls should focus on restricting access, not facilitating open access across departments.

Scanning the hard drive for known malicious file signatures.

Why it fails: File-less malware does not write files to the hard drive, making disk-based signature scanning ineffective. The malicious payload exists only in volatile memory, so looking at the filesystem will not provide any evidence of the infection or allow for the identification of the malicious process's components.

Analyzing the Master File Table (MFT) for deleted entries.

Why it fails: The MFT tracks filesystem metadata but does not store the contents of RAM. Analyzing the MFT is useful for disk forensics and identifying deleted files, but it provides zero visibility into the processes currently executing in memory or the presence of malicious code injected into running system services.

Checking the Windows Event Logs for failed login attempts.

Why it fails: Event logs are useful for identifying authentication-based attacks, but they do not provide visibility into what is happening inside the memory of a running process. Analyzing logins will not reveal the activities of malware that is already operating in RAM, as this activity is generally invisible to standard system logging.

It improves the speed of system startup and file indexing.

Why it fails: PBA actually increases boot time because the user must provide authentication before the system can even load the operating system. It does not improve indexing or performance; rather, it introduces a necessary delay to ensure that unauthorized individuals cannot access the encrypted volumes on the drive.

It ensures that the computer cannot be booted from an external drive.

Why it fails: While PBA is a powerful control, it does not inherently disable external boot devices like USB drives. Disabling external boot must be configured separately in the BIOS or UEFI settings. PBA's primary function is to lock the encryption keys behind a password challenge, not to restrict physical port functionality.

It automatically syncs the encryption keys to a cloud-based backup.

Why it fails: PBA is a local authentication mechanism, not a key management or backup service. Key escrow or recovery is handled by separate administrative processes, such as storing recovery keys in Active Directory or an enterprise disk encryption management server. It has nothing to do with cloud-based key synchronization directly.

Windows Defender Firewall with Advanced Security

Why it fails: Windows Defender Firewall controls network traffic based on rules, not driver loading. It cannot prevent unsigned or malicious kernel-mode drivers from executing. While it is a valuable defense-in-depth component, it does not address driver integrity or rootkit prevention. Consequently, it is not the correct feature for enforcing signed driver requirements.

BitLocker with TPM and PIN

Why it fails: BitLocker provides full-disk encryption to protect data at rest, not to control which drivers can load. While it prevents unauthorized access to the disk, it does not validate driver signatures or block unsigned kernel-mode drivers. Enabling BitLocker would not stop a rootkit from loading if an attacker gains execution privileges. Thus, it does not satisfy the requirement for driver integrity enforcement.

AppLocker with default rules

Why it fails: AppLocker is designed to restrict which applications and scripts users can run, primarily in user mode. It does not enforce kernel-mode driver signing or prevent unsigned drivers from loading. While it can block some executables, it is not the appropriate control for kernel-level driver integrity. Therefore, it does not meet the requirement to allow only approved drivers.

Enable BitLocker with TPM

Why it fails: BitLocker encrypts the disk to protect data at rest, which is useful if the device is lost or stolen. However, it does not protect credentials in memory during runtime or prevent pass-the-hash attacks on a running system. Therefore, it does not directly mitigate the described threats.

Enforce SMB signing

Why it fails: SMB signing ensures the integrity and authenticity of SMB communications, preventing man-in-the-middle attacks and relay attacks. However, it does not protect credentials stored in memory or prevent pass-the-hash. While valuable, it does not directly mitigate credential theft from endpoint memory. Therefore, it is not a correct choice for this scenario.

Deploy Windows Defender Firewall with domain profile

Why it fails: Windows Defender Firewall controls network traffic but does not protect credentials in memory or prevent credential dumping. It can limit lateral movement but does not directly address pass-the-hash or credential theft. Thus, it is not a direct mitigation for the specified threats.

Software Restriction Policies (SRP)

Why it fails: SRP is an older feature that also provides application whitelisting, but it is deprecated in favor of AppLocker and lacks some of the flexibility and rule types (e.g., publisher rules) that AppLocker offers. It integrates with Group Policy but is not the recommended solution for Windows 10. Therefore, it is not the correct choice.

Windows Defender Application Control (WDAC)

Why it fails: WDAC (formerly Device Guard) is also a Windows feature for application control, but it is primarily designed for stronger, kernel-level enforcement and is often used in high-security environments. While it can be used for whitelisting, it does not integrate as seamlessly with Group Policy and is more complex to manage. The scenario specifies Group Policy integration and rule types that align with AppLocker. Thus, WDAC is not the best fit here.

Windows Defender Firewall

Why it fails: Windows Defender Firewall controls network traffic, not application execution. It cannot prevent users from running unauthorized executables. While it is a security feature, it does not provide application whitelisting. Hence, it is not the correct answer for this requirement.

Resource Monitor

Why it fails: Resource Monitor shows real-time CPU, memory, disk, and network usage per process, but it does not provide details about loaded modules or memory content. It cannot identify injected code. Therefore, it is not suitable for inspecting process memory for fileless malware.

Task Manager

Why it fails: Task Manager provides basic information about running processes, such as CPU and memory usage, but it does not allow deep inspection of process memory or loaded modules. It cannot reveal injected code or suspicious memory regions. Thus, it is not adequate for detecting fileless malware.

Event Viewer

Why it fails: Event Viewer displays system and application logs, which may contain indicators of compromise, but it does not inspect process memory. Fileless malware often leaves few traces in event logs. While useful for correlating events, it cannot directly detect code injection. Hence, it is not the correct tool for this task.

BitLocker with a startup key stored on a USB flash drive

Why it fails: A startup key on a USB drive provides pre-boot authentication, but it requires the user to insert the USB drive at every boot. If the USB drive is lost or stolen with the laptop, the protection is defeated. It also adds operational burden and does not leverage the TPM to seal keys to the platform. This configuration is weaker than a TPM and PIN combination for the stated threat model.

BitLocker with TPM-only protector and no PIN

Why it fails: TPM-only BitLocker protects against offline attacks when the drive is removed, but it does not require a pre-boot PIN. An attacker who steals the laptop can boot it and may exploit a cold-boot attack to extract keys from memory, or use a DMA attack. The scenario explicitly asks to minimize cold-boot risk, so a configuration without pre-boot authentication is insufficient even though it encrypts the drive.

EFS encryption of the ePHI folders with user certificates

Why it fails: EFS encrypts individual files and folders, not the entire drive, and it relies on user certificates and keys that may be cached in memory. If the drive is removed and attached to another system, an attacker may be able to access unencrypted areas or recover keys. EFS does not provide pre-boot authentication and is not a full disk encryption solution, so it does not meet the requirement to protect all data if the laptop is lost.

BitLocker Drive Encryption

Why it fails: BitLocker encrypts the contents of a drive to protect data at rest if the device is lost or stolen. It does not detect or remove malware, does not scan email attachments, and does not provide cloud-based protection or signature updates. While it is a valuable built-in security feature, it addresses confidentiality of stored data rather than malware prevention, so it is not the right recommendation for this scenario.

Windows Information Protection (WIP)

Why it fails: Windows Information Protection helps separate personal and corporate data and can prevent accidental data leakage, but it is not an antivirus engine. It does not scan for malware, provide cloud-based threat intelligence, or update virus definitions. WIP is a data loss prevention feature, so it does not address the requirement to protect endpoints from malware delivered via email or web browsing.

Windows Defender Firewall

Why it fails: Windows Defender Firewall filters network traffic and can block unauthorized inbound and outbound connections, but it does not scan files for malware, provide cloud-based protection, or update virus definitions. It is a network security control, not an antivirus solution. While it is a built-in Windows feature, it does not meet the requirement for real-time antivirus scanning of email attachments and web downloads.

/etc/hosts

Why it fails: /etc/hosts maps hostnames to IP addresses for local name resolution. An attacker could modify it to redirect traffic or block security updates, but it does not contain scheduled tasks or commands that execute automatically. It is not a persistence mechanism for running code at boot or on a schedule. Therefore, it is not the artifact to examine first when looking for scheduled tasks.

/var/log/auth.log

Why it fails: /var/log/auth.log records authentication events, including successful and failed logins and sudo usage. It can help trace the attacker's actions but does not store scheduled tasks. While it might show when a cron job ran or a user logged in, it does not contain the cron configuration itself. The team needs to find the persistence mechanism, so this log is a supporting artifact, not the primary one for scheduled tasks.

/etc/passwd

Why it fails: /etc/passwd stores user account information such as usernames, UIDs, home directories, and login shells. While an attacker might add a rogue account, the file does not contain scheduled tasks or commands that run automatically at boot. Examining it is useful for finding unauthorized users, but it does not reveal cron-based persistence. The scenario specifically asks for scheduled tasks, so this file is not the best first artifact.

Disable User Account Control (UAC) to improve user productivity

Why it fails: Disabling UAC removes the prompt that requires elevation for administrative actions, allowing processes to run with higher privileges without user consent. This increases the risk of privilege escalation and silent malware execution. UAC is a security boundary that helps prevent unauthorized changes, so disabling it is the opposite of hardening. It would weaken endpoint security rather than reduce the attack surface.

Install a second third-party antivirus alongside Microsoft Defender Antivirus

Why it fails: Running two antivirus products simultaneously can cause performance issues, conflicts, and false positives, and it may force Microsoft Defender Antivirus into passive mode. It does not add layered protection in a reliable way and can leave gaps if one product interferes with the other. The scenario asks for hardening measures, and installing a competing antivirus is not a recommended way to reduce attack surface.

Enable the Guest account and assign it a blank password for temporary access

Why it fails: Enabling the Guest account with a blank password creates an easily exploitable entry point. Attackers can use it to gain initial access or move laterally without credentials. Best practice is to keep the Guest account disabled. This action increases the attack surface rather than reducing it, so it is not an appropriate endpoint hardening measure for the administrator to implement.