Security practice questions

The Event Viewer Security log

Why it fails: The Security log records security-related events like logon attempts and privilege use, but it does not list programs that run at startup. While it might show evidence of malware execution, it does not reveal persistence mechanisms directly. Analyzing the Security log is useful for auditing but not for identifying autostart locations.

The Task Scheduler library

Why it fails: Task Scheduler can be used by malware to schedule tasks, which is a persistence method. However, the question asks for two locations, and while Task Scheduler is valid, the most common and primary locations are the Run key and Startup folders. Task Scheduler is also a persistence mechanism, but it is not as universally checked as the other two. The question specifies 'persistence mechanism' and both A and C are classic. Including E would be correct if three were allowed, but only two are correct.

The folder C:\Windows\System32\drivers\etc\hosts

Why it fails: The hosts file is used for local DNS resolution and can be modified by malware to redirect traffic, but it is not a persistence mechanism. It does not cause programs to run automatically. While it can be part of an attack, it does not maintain persistence across reboots. Therefore, it is not a primary location to check for persistence.

Encrypting File System (EFS)

Why it fails: EFS encrypts individual files and folders but does not protect the entire drive; if the drive is removed, an attacker could access unencrypted files or use recovery tools. EFS also depends on user certificates and can be bypassed if the attacker obtains the user's credentials. It does not meet the requirement of protecting all data at rest when the drive is physically removed.

Storage Spaces with parity

Why it fails: Storage Spaces is a software RAID-like solution for pooling drives and providing redundancy, not encryption. It does not protect data confidentiality if a drive is removed. Parity helps with fault tolerance, not with preventing unauthorized access to data. Thus, it does not satisfy the encryption requirement.

Device Encryption

Why it fails: Device Encryption in Windows 11 requires a TPM and other hardware requirements, and it automatically enables BitLocker. Since the workstation lacks a TPM, Device Encryption cannot be used. It also does not allow the use of a startup PIN as a workaround. Therefore, it is not a viable option in this scenario.

Remote Desktop Protocol with Network Level Authentication

Why it fails: Network Level Authentication strengthens RDP by requiring authentication before a session is established, which reduces RDP-specific attacks. However, the scenario concerns malware from email attachments and malicious websites, not remote desktop exposure. Enabling NLA does not address the stated threats and could unnecessarily open remote access on a workstation that does not need it.

BitLocker Drive Encryption

Why it fails: BitLocker protects data at rest if the device is lost or stolen, which is valuable for a remote laptop, but it does not prevent malware from executing or block malicious attachments and sites. Encryption addresses confidentiality of stored data, not the delivery vectors named in the goal. It therefore does not satisfy the requirement to reduce the attack surface against email and web malware.

Windows Sandbox

Why it fails: Windows Sandbox provides a disposable environment for running untrusted applications, but it is a separate desktop session that the user must deliberately launch. It does not automatically inspect email attachments or block malicious websites during normal daily use. While useful for testing, it does not continuously reduce the attack surface for the remote employee's routine browsing and email.

Disable auditing for logon events to reduce log noise

Why it fails: Disabling auditing would hide evidence of the attack and hinder incident response. Auditing is crucial for detecting and investigating security incidents. Reducing log noise should be done through filtering, not by disabling auditing. Therefore, this action is counterproductive and insecure.

Reset the password for the built-in Administrator account

Why it fails: Resetting the password does not stop the attack and is unnecessary since the account is disabled. The attackers are attempting to guess the password, but disabling the account already prevents successful logon. Changing the password would not block the source IPs. Thus, it is not the best next step.

Enable the built-in Administrator account to monitor its usage

Why it fails: Enabling the built-in Administrator account would create a significant security risk, as it has full privileges and is a prime target. The account is disabled for a reason, and enabling it would allow attackers to potentially gain access if they guess the password. Monitoring should be done without enabling the account. Therefore, this action is not advisable.

Run a full system scan and then restore the backup

Why it fails: Running a full system scan on the infected computer may not remove all malware, especially if it is a rootkit or persistent. The external drive also needs to be scanned. Restoring after scanning the system but not the drive could still introduce malware. Thus, this is not the best sequence.

Restore the system image from the external drive immediately

Why it fails: Restoring from a potentially infected backup could reintroduce the malware or fail if the backup was encrypted. The drive was connected during the infection, so it may be compromised. Scanning it first is necessary to ensure safety. Therefore, immediate restoration is not advisable.

Pay the ransom to get the decryption key

Why it fails: Paying the ransom does not guarantee that files will be decrypted and encourages further criminal activity. It also does not address the security breach. Additionally, the backup may be compromised. Therefore, paying is not the best course of action.

The DNS server settings on the user's device and compare them to the corporate DNS servers.

Why it fails: Comparing DNS settings could reveal a rogue DNS server, but an on-path attacker typically intercepts traffic without changing DNS settings. The certificate warning indicates the attacker is intercepting TLS connections, not necessarily redirecting DNS. Checking DNS first is less direct than examining the certificate chain, which would immediately show the attacker's certificate.

The ARP cache on the user's device to look for duplicate MAC addresses.

Why it fails: Checking the ARP cache can detect ARP poisoning, which is a common on-path attack method on local networks. However, the user is at a coffee shop on Wi-Fi, where ARP spoofing is less likely due to network segmentation, and the certificate warning directly points to TLS interception. The ARP cache might show the gateway's MAC, but that alone does not confirm an on-path attack on TLS.

The Wi-Fi encryption type configured on the user's device to ensure it is using WPA3.

Why it fails: Wi-Fi encryption type affects the wireless link between the device and access point, but an on-path attack can occur even with strong encryption if the attacker controls the access point or uses a rogue AP. The certificate warning is at the TLS layer, not the wireless layer. Checking WPA3 settings would not confirm the presence of an on-path attack and is not the first step.

Encrypting File System (EFS)

Why it fails: EFS encrypts individual files and folders for the user account that encrypted them. It does not protect the entire volume, and if the drive is removed, files not explicitly encrypted remain readable. It also depends on user certificates, which complicates recovery. EFS does not meet the requirement to protect all stored cardholder data at rest.

Windows Defender Firewall

Why it fails: Windows Defender Firewall filters network traffic to block unauthorized inbound and outbound connections. It has no capability to encrypt data stored on a disk, so removing the drive and attaching it elsewhere would still expose the cardholder data. This is a network control, not a data-at-rest protection mechanism.

User Account Control (UAC)

Why it fails: UAC prompts for elevation when administrative actions are attempted, helping prevent unauthorized system changes. It does not encrypt files or volumes, so physical removal of the drive would still allow an attacker to read the data. UAC addresses privilege escalation, not confidentiality of stored data.

The user's account password has expired.

Why it fails: An expired password affects local or domain logon, not the browser's ability to validate a TLS certificate. The browser warning is about certificate trust, which is independent of user credentials. Password expiration would not cause a certificate trust error on a banking website, so this option is unrelated to the symptom.

The website's TLS certificate has expired.

Why it fails: An expired certificate would also cause a warning, but the scenario states the site worked yesterday and the technician verified the system clock. A certificate that expired overnight is possible, but the question asks for the most likely cause given that the clock is correct and the issue appeared suddenly across a working site. A missing root CA better explains a sudden trust failure.

The DNS server is resolving the banking site to an incorrect IP address.

Why it fails: Incorrect DNS resolution could redirect the user to a different server, but that would typically produce a certificate name mismatch rather than a generic untrusted issuer warning. The scenario says the network is functioning, and a DNS issue would more likely affect multiple sites. A missing root CA is the more direct explanation for an untrusted certificate warning.

Evil twin

Why it fails: An evil twin is a rogue wireless access point that mimics a legitimate SSID to intercept traffic. The scenario describes wired workstations on a subnet with correct DHCP and DNS settings, not a wireless association issue. An evil twin would not change DNS resolution for multiple wired clients unless combined with other attacks, making it less likely here.

Domain hijacking

Why it fails: Domain hijacking involves an attacker taking control of a domain's registration, changing its name servers or ownership. That would affect the domain globally, not just several workstations on one subnet. The localized nature of the incorrect resolution points to a local DNS cache poisoning rather than a registry-level domain takeover.

ARP poisoning

Why it fails: ARP poisoning maps an attacker's MAC address to a legitimate IP, enabling man-in-the-middle attacks on the local subnet. It can redirect traffic, but the symptom here is incorrect DNS resolution of specific domains, not general traffic interception. ARP poisoning would not by itself cause banking domains to resolve to an unknown server without also manipulating DNS.

Run a standard format on the drives.

Why it fails: A standard format removes file system structures but does not securely erase the underlying data; recovery tools can still retrieve files. This fails the requirement that data cannot be recovered. A more thorough sanitization method such as overwriting or cryptographic erase is required.

Delete all partitions and create a new one.

Why it fails: Deleting partitions and creating a new one only removes references to the data; the actual file contents remain on the disk and can be recovered with forensic tools. This does not meet the requirement that data cannot be recovered. Proper sanitization such as overwriting or secure erase is necessary.

Physically destroy the hard drives.

Why it fails: Physical destruction ensures data cannot be recovered, but it prevents the laptops from being donated because the drives would be unusable. The requirement is to allow donation, so destruction is too extreme. A sanitization method that preserves the drive is needed instead.

Change the access point to operate on the 5 GHz band only

Why it fails: Moving to 5 GHz changes radio frequency and can reduce interference, but it does not add any authentication or encryption. The SSID would still be open and frames would remain readable by any nearby device. Band selection is a performance and coverage decision, not a security control, so it does not solve the reported exposure.

Disable SSID broadcast on the access point

Why it fails: Hiding the SSID does not encrypt traffic and does not stop other devices from monitoring the wireless medium. Any client already associated, or anyone capturing the association handshake, can still see the network name and the unencrypted frames. This leaves the break-room traffic exposed exactly as reported, so it fails the requirement.

Enable MAC address filtering for known employee devices

Why it fails: MAC filtering only limits which hardware addresses may associate; it provides no encryption or confidentiality. An attacker can observe a permitted MAC address in the clear and clone it, then read all other traffic on the open network. Because the traffic remains unencrypted, this does not protect employee data in the break room.

The workstation is receiving a legitimate software update from the vendor.

Why it fails: Vendor updates typically resolve to consistent, recognizable domains and occur on a scheduled or triggered basis, not every few minutes with random names. Updates also transfer larger payloads over HTTPS, not tiny amounts to changing external addresses. The pattern described does not match normal update behavior and would not explain the randomized DNS lookups.

The workstation is synchronizing its clock with an external NTP server.

Why it fails: NTP synchronization uses UDP port 123 and contacts configured, stable time servers, producing a predictable pattern without DNS queries for random domains. The volume and destination pattern described, with frequent unique names and small data transfers, is inconsistent with time synchronization. Clock sync also would not generate the observed external IP traffic.

The endpoint protection agent is performing a cloud reputation lookup for each file.

Why it fails: Reputation lookups go to the security vendor's known cloud service over HTTPS and are tied to file activity, not to randomly generated domain names. They also occur when files are scanned, not continuously while no user is logged in. This does not account for the regular small outbound transfers to external IP addresses.

Role-based access control (RBAC)

Why it fails: RBAC assigns permissions based on job roles, limiting what an authenticated user can do. It does not prevent credential theft or unauthorized login; it only restricts actions after authentication. While valuable for least privilege, it does not address the stated risk of stolen credentials enabling access.

Single sign-on (SSO)

Why it fails: SSO lets users authenticate once and access multiple applications, improving convenience, but it does not by itself reduce the risk of credential theft. If the single credential is compromised, many systems become accessible. SSO should be combined with MFA, but it is not the primary control to implement for this requirement.

Password manager

Why it fails: A password manager helps users create and store strong, unique passwords, which reduces password reuse. However, it does not prevent an attacker who steals the master password or a stored credential from logging in. It is a useful supplement but not a direct defense against credential theft in the way MFA is.

Run a standard format of the drive from the operating system installer

Why it fails: A standard format rewrites file system structures but leaves the underlying sectors largely intact, so forensic tools can often recover the previous contents. Because the laptops will be reused and the data is sensitive customer information, a quick format does not provide the assurance that the original records are unrecoverable. It is insufficient for this disposal requirement.

Degauss the drive and then reinstall the operating system

Why it fails: Degaussing a magnetic drive erases it, but it also destroys the drive's servo and format information, leaving the unit unusable. It cannot then be reinstalled and reused as required. Degaussing is appropriate when the media will be destroyed or recycled, not when the laptops must return to service with working drives.

Delete all partitions and leave the drive unallocated

Why it fails: Removing partitions only alters the partition table and file system metadata; the data sectors remain readable with recovery software. Anyone with the laptop could recreate a partition and scan for remnants of the customer records. Since the laptops are being reused, this method does not adequately protect the sensitive data.

The employee is using a corporate VPN that assigns an exit node in another country

Why it fails: A VPN would place all of the employee's traffic through one exit node, producing a single apparent location, not two simultaneous countries. The employee also stated they did not travel and the logins occurred five minutes apart from different regions. This does not account for two concurrent successful sessions in separate geographies.

The employee's password was guessed by a brute-force attack

Why it fails: A brute-force attack against a complex password would be slow and would normally trigger lockout or rate-limit alerts, and it would not by itself satisfy the second factor. Since MFA is required, a guessed password alone would not produce two successful authentications from different countries. This does not explain the observed logins.

The multifactor authentication provider is synchronizing time zones incorrectly

Why it fails: Time-zone handling affects how events are displayed, not the source IP addresses recorded by the identity provider. Two logins from genuinely different countries would still represent two distinct network origins. A display or synchronization issue would not create successful authentications from separate geographic locations, so it does not fit the evidence.

The power adapter

Why it fails: The power adapter is already known to be connected to a good outlet, but it could still be faulty. However, a faulty adapter would not cause the system clock to reset. The clock reset points to a CMOS battery issue, so checking the adapter first is less efficient. The adapter might cause charging problems, but not the time reset.

The hard drive

Why it fails: A failing hard drive would not cause the system clock to reset or the battery to stop charging. Hard drive issues typically manifest as slow performance, errors, or boot failures. The symptoms described are unrelated to storage. Therefore, checking the hard drive first is not appropriate.

The RAM

Why it fails: RAM problems usually cause system instability, blue screens, or memory errors, not clock resets or battery charging issues. While faulty RAM can cause various odd behaviors, the specific combination of clock reset and battery not charging is not typical. Checking RAM would not address the primary symptom.