Trick 1: "HTTPS encryption prevents keyloggers from capturing credentials because the browser encrypts all data before it leaves the machine." True or False?
FALSE — HTTPS does not prevent keyloggers from capturing credentials.
This is the most important misconception on this topic, and the exam exploits it regularly. The statement sounds correct because HTTPS does encrypt data before it leaves the machine — that is technically true. But it misunderstands where keyloggers operate.
The gap HTTPS does not cover:
HTTPS encrypts the data at the browser application layer — the moment before the browser sends it to the server. But the user typed that data before the browser processed it. Keystrokes exist as plaintext input events at the OS level, between the keyboard and the application. The keylogger intercepts them there — before the application layer even receives them. HTTPS never sees those keystrokes. It encrypts the output; the keylogger captured the input.
The two protections and what they actually cover:
HTTPS = data in transit (network path between browser and server). Full-disk encryption = data at rest (stored files on the hard drive). Neither = data at input (the act of typing). The keylogger lives at data-at-input. No standard encryption layer touches that moment.
What does help:
Multi-factor authentication — even if the attacker captures the password, the second factor (authenticator app, hardware token) may not be capturable. Dedicated anti-malware for detection. And avoiding the installation vectors that deliver keyloggers in the first place.
Exam tip: When a question describes credential theft despite HTTPS and clean AV, the answer is keylogger. "The user has HTTPS" is a distractor designed to make you think the data path is protected — it is, at the network layer. But the keystroke was already captured before the network was involved.
This is the most important misconception on this topic, and the exam exploits it regularly. The statement sounds correct because HTTPS does encrypt data before it leaves the machine — that is technically true. But it misunderstands where keyloggers operate.
The gap HTTPS does not cover:
HTTPS encrypts the data at the browser application layer — the moment before the browser sends it to the server. But the user typed that data before the browser processed it. Keystrokes exist as plaintext input events at the OS level, between the keyboard and the application. The keylogger intercepts them there — before the application layer even receives them. HTTPS never sees those keystrokes. It encrypts the output; the keylogger captured the input.
The two protections and what they actually cover:
HTTPS = data in transit (network path between browser and server). Full-disk encryption = data at rest (stored files on the hard drive). Neither = data at input (the act of typing). The keylogger lives at data-at-input. No standard encryption layer touches that moment.
What does help:
Multi-factor authentication — even if the attacker captures the password, the second factor (authenticator app, hardware token) may not be capturable. Dedicated anti-malware for detection. And avoiding the installation vectors that deliver keyloggers in the first place.
Exam tip: When a question describes credential theft despite HTTPS and clean AV, the answer is keylogger. "The user has HTTPS" is a distractor designed to make you think the data path is protected — it is, at the network layer. But the keystroke was already captured before the network was involved.
Trick 2: "An antivirus scan returned clean on a system suspected of having a logic bomb. This proves the system does not contain a logic bomb." True or False?
FALSE — a clean antivirus scan does NOT rule out a logic bomb.
This is the central challenge of logic bomb defense, and the exam tests whether you understand why.
Why antivirus cannot detect logic bombs:
Antivirus detection is primarily signature-based — it matches files and code against a database of known malware patterns. A logic bomb is custom-written code, designed for a specific target system. It has never been analyzed, classified, or added to any signature database anywhere. There is no signature to match. The AV scan completes and reports clean because it literally has no definition that applies to this custom code.
The analogy:
Antivirus looking for a logic bomb is like a security checkpoint looking at a photo ID for someone whose photo was never added to the database. If the database does not contain the person's photo, the checkpoint passes them through. The person is still present; the checkpoint simply has no record of them.
What can detect logic bombs:
File integrity monitoring (FIM/Tripwire) — detects the act of planting by alerting when files or scheduled tasks change. Formal change management — creates a record of all changes that can be audited. HIDS behavioral monitoring — may catch anomalous activity during planting or during the dormant phase. Regular auditing of scheduled tasks and scripts — a human reviewer might notice a new or modified script.
Exam tip: "Antivirus returned clean" never rules out a logic bomb. If a question asks what to do about a suspected logic bomb, the correct answer involves FIM, change management, and auditing — not scanning with better AV.
This is the central challenge of logic bomb defense, and the exam tests whether you understand why.
Why antivirus cannot detect logic bombs:
Antivirus detection is primarily signature-based — it matches files and code against a database of known malware patterns. A logic bomb is custom-written code, designed for a specific target system. It has never been analyzed, classified, or added to any signature database anywhere. There is no signature to match. The AV scan completes and reports clean because it literally has no definition that applies to this custom code.
The analogy:
Antivirus looking for a logic bomb is like a security checkpoint looking at a photo ID for someone whose photo was never added to the database. If the database does not contain the person's photo, the checkpoint passes them through. The person is still present; the checkpoint simply has no record of them.
What can detect logic bombs:
File integrity monitoring (FIM/Tripwire) — detects the act of planting by alerting when files or scheduled tasks change. Formal change management — creates a record of all changes that can be audited. HIDS behavioral monitoring — may catch anomalous activity during planting or during the dormant phase. Regular auditing of scheduled tasks and scripts — a human reviewer might notice a new or modified script.
Exam tip: "Antivirus returned clean" never rules out a logic bomb. If a question asks what to do about a suspected logic bomb, the correct answer involves FIM, change management, and auditing — not scanning with better AV.
Trick 3: "A rootkit can be reliably removed by running a complete antivirus scan in Safe Mode, because Safe Mode loads only essential OS drivers and prevents the rootkit from hiding." True or False?
FALSE — Safe Mode does not reliably defeat a kernel-level rootkit.
This is a common misconception that sounds plausible because Safe Mode does limit what software loads at startup. But it does not adequately address kernel-level rootkits.
What Safe Mode actually does:
Safe Mode loads a minimal set of drivers and prevents most third-party software from starting. It was designed to allow troubleshooting of driver conflicts and startup issues. It does reduce the attack surface of what's running — but it does not prevent the OS kernel from loading, and a rootkit that has embedded itself in the kernel may persist through Safe Mode because the kernel itself is what loads.
This is a common misconception that sounds plausible because Safe Mode does limit what software loads at startup. But it does not adequately address kernel-level rootkits.
What Safe Mode actually does:
Safe Mode loads a minimal set of drivers and prevents most third-party software from starting. It was designed to allow troubleshooting of driver conflicts and startup issues. It does reduce the attack surface of what's running — but it does not prevent the OS kernel from loading, and a rootkit that has embedded itself in the kernel may persist through Safe Mode because the kernel itself is what loads.
Trick 4: "Logic bombs are primarily delivered through phishing emails — they are a form of external attack similar to other email-delivered malware." True or False?
FALSE (as a primary characterization) — logic bombs are primarily an insider threat, not an email-delivery attack.
This misconception merges the South Korea 2013 example — where a phishing email delivered a Trojan that contained a logic bomb — with the general definition of logic bombs. The delivery method in that attack was email, but that is a special case, not the defining characteristic.
Why logic bombs are primarily an insider threat:
A logic bomb requires planting — inserting malicious code into a specific system in a way that will survive and execute on schedule. External attackers who deliver a logic bomb via phishing first need to get remote access, then plant the bomb. This is a two-stage attack.
The more common and more dangerous scenario for organizations is the insider: a sysadmin, developer, or IT staff member who has legitimate access to production systems can directly plant a logic bomb in a scheduled task, script, or configuration file during their normal working hours — no phishing required, no exploit needed, no network detection. They have the access; they use it.
The insider threat angle is what makes logic bombs distinctively dangerous:
They exploit trusted insiders — people who can touch production systems without raising alarms. The South Korea attack is a nation-state example using an email delivery chain; the internal disgruntled employee variant is the more common real-world scenario that organizations face.
Exam tip: When a question describes a logic bomb, think insider threat first. The defining characteristics — custom code, no AV signature, planted by someone with access — align more naturally with an insider than with an external phishing attack. If the question asks "who typically plants a logic bomb?", the answer is "a disgruntled insider with system access," not "an external attacker via email."
This misconception merges the South Korea 2013 example — where a phishing email delivered a Trojan that contained a logic bomb — with the general definition of logic bombs. The delivery method in that attack was email, but that is a special case, not the defining characteristic.
Why logic bombs are primarily an insider threat:
A logic bomb requires planting — inserting malicious code into a specific system in a way that will survive and execute on schedule. External attackers who deliver a logic bomb via phishing first need to get remote access, then plant the bomb. This is a two-stage attack.
The more common and more dangerous scenario for organizations is the insider: a sysadmin, developer, or IT staff member who has legitimate access to production systems can directly plant a logic bomb in a scheduled task, script, or configuration file during their normal working hours — no phishing required, no exploit needed, no network detection. They have the access; they use it.
The insider threat angle is what makes logic bombs distinctively dangerous:
They exploit trusted insiders — people who can touch production systems without raising alarms. The South Korea attack is a nation-state example using an email delivery chain; the internal disgruntled employee variant is the more common real-world scenario that organizations face.
Exam tip: When a question describes a logic bomb, think insider threat first. The defining characteristics — custom code, no AV signature, planted by someone with access — align more naturally with an insider than with an external phishing attack. If the question asks "who typically plants a logic bomb?", the answer is "a disgruntled insider with system access," not "an external attacker via email."
Performance Task: You are the lead security analyst at a healthcare organization. A network administrator named Tobias has given notice and will be leaving in two weeks. During a routine audit triggered by his notice, you discover an unusual scheduled task on one of the organization's primary servers. The task was created three days ago by Tobias's account. It is configured to run at 3:00 AM on his last day of employment. The task script calls a PowerShell command that you recognize as a recursive deletion command targeting the organization's patient records backup directory. Tobias claims he has no knowledge of this task and that his account may have been used without his authorization. Describe your complete investigation and response: what you suspect, how you verify, what you do if the logic bomb is confirmed, and what long-term controls you recommend to prevent recurrence.
Model Answer:
Initial Assessment — What You Suspect:
The evidence strongly suggests a time-based logic bomb planted by Tobias as an insider threat. The indicators are: (1) a scheduled task created by his account three days ago — after he gave notice; (2) a trigger time set to his last day of employment at 3:00 AM (low staffing, delayed discovery); (3) a payload targeting patient records backups — the deletion of which would maximize damage to a healthcare organization; (4) a plausible "my account was compromised" denial that cannot be immediately confirmed or denied. The timing correlation between giving notice and creating the task is the strongest indicator. A genuine external account compromise would be unusual for an insider's account that has not previously been compromised and that happened to target exactly the most sensitive backup directory just as the admin is leaving.
Immediate Response Steps:
(1) Disable the scheduled task immediately — you have found it with time to spare. Disable it before 3:00 AM on his last day. Document its content, creation timestamp, and configuration before disabling. (2) Preserve evidence — create a forensic copy of the scheduled task configuration, the PowerShell script it references, and all relevant log entries (authentication logs showing when Tobias's account was active on that server, creation logs for the task). Chain of custody matters if this leads to legal action. (3) Review all systems Tobias had access to — do not assume this is the only planted bomb. Audit every server, scheduled task, script, database maintenance job, and configuration file that his account could have modified in the past three days (and potentially longer — check when his notice was given as a starting investigation date). (4) Investigate the "compromised account" claim — review authentication logs for any unusual access patterns: logins from unusual IPs or hours, failed authentication attempts, VPN access outside normal hours. If the account was genuinely compromised by an external actor, there will be indicators. If there are none and the only access during the task creation window was from Tobias's normal workstation at normal hours, the compromise claim is unlikely. (5) Lock down Tobias's access immediately — regardless of culpability determination, an employee under investigation for planting a logic bomb should not retain access to production systems during the remaining two weeks. This is both a security and evidentiary measure. Coordinate with HR and legal counsel before the conversation with Tobias.
If the Logic Bomb Is Confirmed:
(1) Consult legal counsel — logic bomb planting targeting patient records backup in a healthcare organization may trigger HIPAA breach notification obligations, constitute computer fraud, and support civil and/or criminal action. Legal counsel guides what to preserve, what to disclose, and how to proceed with the employee. (2) Notify executive leadership and the CISO — this is a material security incident, not a routine IT problem. Escalation is required. (3) Audit all remaining access privileges — verify that Tobias's account has been disabled across all systems: Active Directory, VPN, cloud services, databases, source code repositories. Check for any backdoor accounts, new accounts created, or permission changes made by his account in the past several weeks. (4) Complete the backup audit — confirm that the backup directory that was targeted is intact and that backups are valid. In a healthcare environment, patient records backup integrity is a compliance and operational requirement. (5) Conduct a broader audit for dormant tasks — if Tobias planted one bomb, he may have planted others with different trigger dates or conditions. Every scheduled task and script his account could have touched must be reviewed.
Long-Term Controls to Prevent Recurrence:
(1) File integrity monitoring — deploy FIM/Tripwire on all production servers to alert on any modification to scheduled tasks, scripts, and critical configuration files. If FIM had been running, the task creation would have generated an alert at the moment it was created, three days ago, rather than being found only because of a routine audit. (2) Formal change management — any new scheduled task or script change on production servers must be submitted through a change management system, reviewed, and approved before implementation. An admin creating a scheduled task without a corresponding approved change request is immediately visible and actionable. (3) Separation of duties for offboarding — establish a formal offboarding security checklist triggered at notice submission (not at the final day): immediate access review, audit of all systems touched in the past 30 days, account privilege reduction during notice period for sensitive systems. (4) Least privilege enforcement — network administrators should not have direct shell access to patient records backup directories. RBAC (role-based access control) limits blast radius: if Tobias could not write to the backup directory target, the bomb's payload would fail even if it ran. (5) Mandatory separation of duties for backup management — backup management and the ability to delete backup data should be split from network administration. A single admin who manages the network should not also be able to delete the organization's only backup copies.
Initial Assessment — What You Suspect:
The evidence strongly suggests a time-based logic bomb planted by Tobias as an insider threat. The indicators are: (1) a scheduled task created by his account three days ago — after he gave notice; (2) a trigger time set to his last day of employment at 3:00 AM (low staffing, delayed discovery); (3) a payload targeting patient records backups — the deletion of which would maximize damage to a healthcare organization; (4) a plausible "my account was compromised" denial that cannot be immediately confirmed or denied. The timing correlation between giving notice and creating the task is the strongest indicator. A genuine external account compromise would be unusual for an insider's account that has not previously been compromised and that happened to target exactly the most sensitive backup directory just as the admin is leaving.
Immediate Response Steps:
(1) Disable the scheduled task immediately — you have found it with time to spare. Disable it before 3:00 AM on his last day. Document its content, creation timestamp, and configuration before disabling. (2) Preserve evidence — create a forensic copy of the scheduled task configuration, the PowerShell script it references, and all relevant log entries (authentication logs showing when Tobias's account was active on that server, creation logs for the task). Chain of custody matters if this leads to legal action. (3) Review all systems Tobias had access to — do not assume this is the only planted bomb. Audit every server, scheduled task, script, database maintenance job, and configuration file that his account could have modified in the past three days (and potentially longer — check when his notice was given as a starting investigation date). (4) Investigate the "compromised account" claim — review authentication logs for any unusual access patterns: logins from unusual IPs or hours, failed authentication attempts, VPN access outside normal hours. If the account was genuinely compromised by an external actor, there will be indicators. If there are none and the only access during the task creation window was from Tobias's normal workstation at normal hours, the compromise claim is unlikely. (5) Lock down Tobias's access immediately — regardless of culpability determination, an employee under investigation for planting a logic bomb should not retain access to production systems during the remaining two weeks. This is both a security and evidentiary measure. Coordinate with HR and legal counsel before the conversation with Tobias.
If the Logic Bomb Is Confirmed:
(1) Consult legal counsel — logic bomb planting targeting patient records backup in a healthcare organization may trigger HIPAA breach notification obligations, constitute computer fraud, and support civil and/or criminal action. Legal counsel guides what to preserve, what to disclose, and how to proceed with the employee. (2) Notify executive leadership and the CISO — this is a material security incident, not a routine IT problem. Escalation is required. (3) Audit all remaining access privileges — verify that Tobias's account has been disabled across all systems: Active Directory, VPN, cloud services, databases, source code repositories. Check for any backdoor accounts, new accounts created, or permission changes made by his account in the past several weeks. (4) Complete the backup audit — confirm that the backup directory that was targeted is intact and that backups are valid. In a healthcare environment, patient records backup integrity is a compliance and operational requirement. (5) Conduct a broader audit for dormant tasks — if Tobias planted one bomb, he may have planted others with different trigger dates or conditions. Every scheduled task and script his account could have touched must be reviewed.
Long-Term Controls to Prevent Recurrence:
(1) File integrity monitoring — deploy FIM/Tripwire on all production servers to alert on any modification to scheduled tasks, scripts, and critical configuration files. If FIM had been running, the task creation would have generated an alert at the moment it was created, three days ago, rather than being found only because of a routine audit. (2) Formal change management — any new scheduled task or script change on production servers must be submitted through a change management system, reviewed, and approved before implementation. An admin creating a scheduled task without a corresponding approved change request is immediately visible and actionable. (3) Separation of duties for offboarding — establish a formal offboarding security checklist triggered at notice submission (not at the final day): immediate access review, audit of all systems touched in the past 30 days, account privilege reduction during notice period for sensitive systems. (4) Least privilege enforcement — network administrators should not have direct shell access to patient records backup directories. RBAC (role-based access control) limits blast radius: if Tobias could not write to the backup directory target, the bomb's payload would fail even if it ran. (5) Mandatory separation of duties for backup management — backup management and the ability to delete backup data should be split from network administration. A single admin who manages the network should not also be able to delete the organization's only backup copies.