Endpoint Protection practice questions

rpm -Va

Why it fails: rpm -Va is used on RPM-based systems (RedHat/CentOS), not Debian/Ubuntu.

debsums -ac

Why it fails: While debsums checks sums, dpkg --verify is the native dpkg suite tool for comprehensive file state verification.

apt-get check-integrity

Why it fails: apt-get check-integrity is not a valid apt-get command; apt verifies dependency graphs.

Apple Configurator tethered supervision only

Why it fails: Apple Configurator prepares devices, but ongoing enforcement requires an MDM solution like VPP/managed distribution.

Managed Open In restriction

Why it fails: Managed Open In prevents corporate data from leaking into personal apps, but does not control app installation.

Enterprise App Sideloading via Developer Profiles

Why it fails: Sideloading via developer profiles bypasses App Store vetting and is insecure for standard enterprise management.

aa-enforce -r /etc/apparmor.d/usr.sbin.daemon

Why it fails: aa-enforce is used to set profiles to enforcing mode, not complain mode.

systemctl set-mode apparmor=complain

Why it fails: systemctl does not take an apparmor mode argument; AppArmor is managed via its own utilities.

apparmor_parser -C /etc/apparmor.d/usr.sbin.daemon

Why it fails: The apparmor_parser command with -C checks policy syntax rather than dynamically changing the running profile mode for a single application.

-a always,exclude -F path=/etc/passwd

Why it fails: Excluding paths prevents audit logging rather than enforcing monitoring.

sysctl -w kernel.audit=1

Why it fails: sysctl configures kernel runtime parameters, not auditd file watch rules.

-e 0

Why it fails: -e 0 disables the audit system entirely.

Running chmod 000 /bin/sh

Why it fails: Removing execute permissions from the shell breaks the operating system environment.

Editing /etc/fstab to mount /tmp as read-only

Why it fails: Making /tmp read-only affects temporary file writes, not core dump generation.

Modifying /etc/resolv.conf to block DNS queries

Why it fails: resolv.conf configures DNS name server resolvers, unrelated to core dumps.

Reflashing the physical UEFI/BIOS firmware of the endpoint motherboard

Why it fails: EDR agents do not manage or reflash physical motherboard UEFI/BIOS firmware remotely.

Rebuilding the hardware RAID controller striping configuration

Why it fails: RAID configurations are managed via hardware utility controllers, not EDR software.

Windows Firewall with Advanced Security

Why it fails: Windows Firewall with Advanced Security controls network traffic, not application execution. It cannot restrict which executables are allowed to run on an endpoint. While it can block network-based attacks, it does not provide application whitelisting capabilities. Therefore, it does not meet the requirement for preventing unauthorized executables from running.

User Account Control (UAC)

Why it fails: User Account Control (UAC) prompts for elevation when administrative tasks are attempted, but it does not prevent unauthorized applications from running. A standard user can run any executable that does not require elevation. UAC is not an application whitelisting feature and therefore does not satisfy the requirement for granular application control.

Software Restriction Policies (SRP)

Why it fails: Software Restriction Policies (SRP) is a legacy feature available in older Windows versions and can restrict applications based on path, hash, or certificate. However, SRP is deprecated and lacks the granularity and kernel-level enforcement of AppLocker or WDAC. While it can be used, it is not the best choice for modern Windows 10 endpoints, and the question asks for features that can achieve the goal effectively.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services

Why it fails: The Services key contains configuration for Windows services, which can be set to start automatically. Malware can create malicious services for persistence, but this requires more complexity and privileges. The Run key is more commonly used due to its simplicity. While Services is a valid persistence location, it is not the most common for typical malware, and the question asks for a commonly used location.

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders

Why it fails: The Shell Folders key defines the paths to special folders like Desktop, Start Menu, and Documents. While malware might modify these to redirect folder locations, it is not a primary autostart location. Attackers typically use Run keys or scheduled tasks for persistence. Thus, this key is not the most common location for automatic execution on startup.

HKEY_CLASSES_ROOT\exefile\shell\open\command

Why it fails: This key defines the command used to open executable files. Malware could hijack it to intercept execution, but this is a less common persistence method and often breaks functionality. It is not a standard autostart location like the Run key. Therefore, it is not the correct answer for a commonly used startup location.

System Event Log (Event ID 7045)

Why it fails: Event ID 7045 records service installation, not PowerShell execution, and the System log holds no decoded script text. It is tempting because service creation often follows malicious scripts, but the decoded contents require PowerShell script block logging in the PowerShell Operational log, not the System log.

Security Event Log (Event ID 4688)

Why it fails: Event ID 4688 logs process creation with the command line, but encoded script blocks stay encoded there; the decoded contents are not written. It is tempting because 4688 captures the suspicious PowerShell invocation itself, yet decoding requires PowerShell script block logging, which records the expanded script.

Windows Defender Operational Log (Event ID 1116)

Why it fails: Event ID 1116 records Defender malware detections, not PowerShell script-block contents; it never decodes encoded commands. It is tempting because Defender logs capture suspicious activity, but the decoded script text is written by PowerShell script block logging into the PowerShell Operational log instead.

Windows Defender Application Control (WDAC)

Why it fails: WDAC restricts which binaries and drivers may execute, blocking untrusted code but leaving LSASS memory unprotected from credential dumping by already-permitted processes. It tempts because application control is a strong hardening measure, and it would be correct where the goal is preventing unauthorised executables from running at all.

User Account Control (UAC)

Why it fails: UAC gates privilege elevation through consent prompts; it does not isolate LSASS memory, and pass-the-hash reuses captured hashes without triggering an elevation prompt. It tempts because UAC is a familiar built-in hardening feature, and it would be the right control when the requirement is limiting standard users' administrative rights.

BitLocker Drive Encryption

Why it fails: BitLocker encrypts data at rest on the disk; it does not virtualise or protect the LSASS process memory where cached credential hashes reside. It tempts because encryption is a core endpoint-hardening control, and it would be the right choice when the requirement is protecting data on lost or stolen devices.

Software Update Groups

Why it fails: Software Update Groups merely organise updates for deployment and reporting; they carry no scheduling or deadline behaviour. They are the right choice when bundling updates for a phased rollout, but they cannot defer installation or restart until outside active hours.

Automatic Deployment Rules (ADR)

Why it fails: ADRs create and distribute software update deployments on a schedule; they do not themselves enforce installation timing or suppress reboots during active hours. It is tempting because ADRs automate patching, but the maintenance-window and restart behaviour requirement is met by client settings and maintenance windows.

Client Settings - Computer Restart

Why it fails: Client Settings - Computer Restart defines grace periods and notifications before a forced reboot, not when updates install. It suits controlling restart prompts generally, yet the requirement is to install patches outside active hours, which maintenance windows govern.

Local Users and Groups (lusrmgr.msc)

Why it fails: Local Users and Groups creates and manages accounts but exposes no password complexity, minimum length, or lockout threshold settings. It is tempting because it is the natural console for standalone local accounts, and it would be correct for adding or removing local users and group memberships on a non-domain server.

Group Policy Management Console (gpmc.msc)

Why it fails: Group Policy Management Console edits domain-linked Group Policy Objects, which do not apply to standalone servers outside Active Directory. It is tempting because GPOs are the standard mechanism for password and lockout policy, and it would be correct for domain-joined endpoints receiving policy from a domain controller.

System Configuration (msconfig.exe)

Why it fails: System Configuration controls startup services, boot options, and diagnostic modes; it contains no account policy settings at all. It is tempting because it is a familiar built-in administrative tool, and it would be correct for troubleshooting startup problems or disabling services during diagnosis.

Computer Configuration -> Policies -> Administrative Templates -> Network -> Network Connections -> Windows Defender Firewall

Why it fails: Administrative Templates under Network Connections expose legacy firewall toggles and connection settings, not the outbound default-block action, which sits in the Windows Defender Firewall with Advanced Security node. It is tempting because Administrative Templates are the usual home for GPO policy, but profile-level firewall rules are configured elsewhere.

Computer Configuration -> Preferences -> Control Panel Settings -> Network Options

Why it fails: Preferences Control Panel Settings configure legacy network options such as mapped drives and VPN entries, not firewall profile behaviour, so no outbound default-block rule is applied. It is tempting because Preferences do deploy network configuration via GPO, but firewall policy lives under Windows Defender Firewall with Advanced Security.

Computer Configuration -> Policies -> Software Restriction Policies

Why it fails: Software Restriction Policies govern which executables may run, not firewall traffic direction; outbound filtering lives under Windows Defender Firewall with Advanced Security, where the outbound default action is set to Block. SRP would be right for whitelisting applications on legacy endpoints.

/etc/fstab

Why it fails: /etc/fstab defines which filesystems mount at boot and their mount options; it cannot prevent a kernel module from loading. It is tempting because fstab controls device behaviour at startup, but that is storage mounting, not module blacklisting, which requires /etc/modprobe.d/ entries.

/boot/grub/grub.cfg

Why it fails: grub.cfg supplies bootloader kernel command-line parameters at startup; it does not persistently blacklist modules from loading later. It is tempting because kernel parameters can disable hardware features, but module blacklisting is configured in /etc/modprobe.d/ files that modprobe consults.

/etc/sysctl.conf

Why it fails: /etc/sysctl.conf holds runtime kernel parameter settings such as IP forwarding and SYN cookies; it does not control module loading. It is tempting because sysctl does tune kernel behaviour, but module blacklisting belongs in /etc/modprobe.d/ configuration files read by modprobe.

fdisk partition manager

Why it fails: fdisk creates and edits partition tables; it never interacts with LUKS keyslots or TPM sealing, so automatic unlock cannot occur. It is tempting because partitioning precedes encryption, but the required integration is a tool such as systemd-cryptenrolment that binds the LUKS keyslot to a TPM 2.0 PCR policy.

gnupg keychain agent

Why it fails: GnuPG's agent manages OpenPGP and SSH private keys in a user session; it cannot unseal a LUKS volume at boot before any user logs in. It is tempting because it is a key-management tool, but TPM-based automatic decryption needs a keyslot bound to TPM PCR measurements via systemd-cryptenrolment.

cryptsetup-reencrypt

Why it fails: cryptsetup-reencrypt changes the encryption parameters or keys of an existing LUKS volume; it does not enrol a TPM or enable automatic unlocking. It is tempting because it is a cryptsetup subcommand, but the task requires binding a keyslot to TPM 2.0 PCRs, which systemd-cryptenrolment performs.

Application sideloading enforcement

Why it fails: Application sideloading enforcement governs which APK sources are permitted, an application-layer control that never inspects 802.11 frames or certificate chains, so rogue access points and MitM interception go undetected. It is tempting because sideloading is a genuine Android risk, and it would be correct where the requirement is blocking untrusted app installs.

Containerized workspace isolation

Why it fails: Containerised workspace isolation separates corporate data from personal apps on the device, an on-device data-separation control that does not analyse Wi-Fi frames or TLS certificates. It is tempting because containers are central to BYOD security, and it would be correct where the requirement is preventing data leakage between personal and business apps.

Remote wipe capability for lost devices

Why it fails: Remote wipe is a remediation action triggered after a device is reported lost; it performs no continuous network monitoring, so it cannot identify a rogue access point or an active MitM session. It is tempting because it is a core MTD feature, and it would be correct where the requirement is protecting data on a misplaced handset.

Stop and disable the Windows Plug and Play service

Why it fails: Disabling Plug and Play prevents device enumeration entirely, blocking smart cards and input devices alongside storage. It is tempting as a blunt lockdown, but the policy demands selective blocking; the correct approach restricts only the USB mass storage device class while permitting other device types.

Enable BitLocker To Go on all internal drives

Why it fails: BitLocker To Go encrypts removable drives; it does not block USB mass storage or permit smart cards and input devices. It is tempting because it protects data on removable media, which would be correct if the requirement were to enforce encryption on USB drives rather than deny their use.

Disable the USB Enhanced Host Controller Interface (EHCI) in BIOS across all endpoints

Why it fails: Disabling EHCI removes USB 2.0 controller support, affecting all USB devices including smart cards and keyboards. It is tempting because it is a firmware-level block, but the requirement is device-class-specific; the correct approach targets the mass storage driver while leaving other USB classes operational.

/etc/ssh/sshd_config

Why it fails: sshd_config governs SSH daemon behaviour such as authentication and forwarding, and contains no umask directive, so setting it there changes nothing about file permissions. It is the correct file when hardening remote access settings, not default file-creation masks.

/etc/security/limits.conf

Why it fails: limits.conf controls per-user resource limits such as process counts and open files, not the default permission mask applied at file creation. It is the right file for constraining resource consumption, not for enforcing system-wide umask values.

/etc/environment

Why it fails: PAM reads /etc/environment for environment variables, not shell umask defaults, so it will not set a system-wide umask for login shells. It is tempting because it configures system-wide variables, and would be correct for setting variables such as PATH or locale for all users.

Uninstall the third-party disk encryption driver permanently

Why it fails: Removing the encryption driver leaves endpoints unencrypted and destroys access to existing encrypted volumes, addressing the symptom by eliminating a required control. It is tempting because the filter driver is the conflict source, and it would be correct only if the organisation had approved retiring that encryption product.

Reinstall the Windows operating system with a clean image

Why it fails: Reimaging discards forensic evidence and configuration state, and the conflicting filter driver would simply be reinstalled, so the conflict recurs. It is tempting as a guaranteed clean baseline, and it would be correct after the driver conflict is diagnosed and remediation is confirmed to require a rebuild.

Disable Secure Boot in UEFI settings

Why it fails: Secure Boot verifies bootloader signatures and does not govern kernel driver loading order or filter driver conflicts, so the BSOD persists while boot integrity weakens. It is tempting as a boot-troubleshooting step, and it would be correct when unsigned boot components, not drivers, block startup.

lsof -i

Why it fails: lsof -i lists open network sockets via the same hooked system calls, so a user-space rootkit hiding PIDs also hides its sockets. It tempts for spotting suspicious connections, but it would be correct for mapping listening ports, not bypassing kernel-level tampering.

netstat -anp

Why it fails: netstat -anp lists sockets and their owning PIDs via /proc, so it reads the same user-space-visible data a hooked system call table would falsify, giving no independent kernel-memory comparison. It is tempting because netstat is the standard tool for mapping listening ports to processes during triage, and would suit identifying a network-facing backdoor's PID.

ps aux --forest

Why it fails: ps aux --forest reads /proc through hooked system calls, so a user-space rootkit concealing PIDs also conceals them here. It tempts for visualising parent-child process trees, but it would be correct on a clean host, not one with tampered syscall tables.