DarkComet is a Remote Access Trojan (RAT) developed and distributed in the late 2000s and early 2010s. It became one of the most widely documented examples of a comprehensive keylogging platform because of how clearly it demonstrated what modern keyloggers capture — and because it was used in demonstrations, malware research, and unfortunately in real attacks.
What DarkComet included: Beyond the standard remote access shell that RATs provide, DarkComet's keylogging module captured every keystroke and displayed a complete transcript in the attacker's control panel. The transcript was not just the final text — it showed the exact sequence of characters including spaces, deletions, and corrections. If a user typed "passw" then pressed Backspace twice and typed "sword1!", the log showed exactly that sequence. The attacker knew not just what the final password was, but how it was typed.
The Professor Messer demonstration: In a controlled demonstration environment, a researcher typed "username: professormesser" and "password: notarealpassword" into a Notepad document. The DarkComet keylogger on the right side of the screen displayed the complete captured transcript — including the space the researcher typed and then deleted with the Delete key before completing the entry. The keylogger captured that correction and preserved it. This level of detail — capturing the user's typing behavior, not just their final input — demonstrates that keyloggers record a complete interaction transcript, not just a simple list of characters.
DarkComet's additional capture capabilities: The same tool could take screenshots at configured intervals, monitor clipboard contents, capture instant messaging sessions, and log search queries. A victim running DarkComet would have their entire computer session documented — visually and textually — and transmitted to the attacker's server.
The encryption bypass: In the demonstration, the Notepad document was not an encrypted communication channel — but the principle holds for banking sites with full HTTPS. The keylogger captures the keystrokes before the browser processes and encrypts them. Whether the user is typing into Notepad, a login form, or an encrypted corporate portal makes no difference to the keylogger. The keystrokes exist as plaintext at the moment of capture.
Exam takeaways: (1) Keyloggers capture keystroke sequences — including corrections — not just final output. (2) Clipboard logging captures passwords that were never typed. (3) Screenshots provide a visual timeline of user activity. (4) Encryption (HTTPS, full-disk) does not protect against keyloggers because the capture occurs before encryption is applied. (5) DarkComet is a RAT — it combines keylogging with remote access in a single package.
On March 19, 2013, employees at South Korean banks and broadcasting companies received phishing emails. The emails were designed to look like legitimate bank communications and included malicious attachments. Employees who opened the attachments installed a Trojan onto their systems. The Trojan was quiet — it appeared to do nothing.
The 24-hour delay: The Trojan contained a time-based logic bomb set to activate exactly 24 hours after installation — on March 20, 2013, at 2:00 PM local time. During those 24 hours, the Trojan sat dormant. No unusual network traffic. No performance degradation. Nothing to detect. Standard antivirus, even with current signatures, had nothing to match against because this bomb had been written specifically for this attack and had no prior known signature.
The detonation: At 2:00 PM on March 20, the logic bomb activated simultaneously across all infected systems. The payload deleted storage contents and wiped the Master Boot Record (MBR) — the critical sector of the hard disk that contains the instructions for loading the operating system. After the deletion, the systems rebooted automatically.
The result: With no MBR, the systems could not locate or start an operating system. Screens displayed: "Boot device not found. Please install an operating system on your hard disk." The machines were effectively bricked. Thousands of workstations at banks and broadcasters simultaneously became nonfunctional.
The ATM catastrophe: The most operationally damaging outcome was the impact on ATMs. Bank ATMs ran on the same operating systems and were infected by the same Trojan. At 2:00 PM, ATMs across South Korea simultaneously hit the same trigger and were wiped. Customers attempting to withdraw money were greeted by the "Boot device not found" error. The banking infrastructure went down in a coordinated, simultaneous collapse.
Why simultaneous detonation mattered: A logic bomb's power in a coordinated attack is not just the payload — it is the timing. If systems had failed one by one over hours or days, IT teams could begin investigating and potentially halt the spread. Simultaneous detonation overwhelmed response capacity: every affected organization was hit at the same moment, and no single investigation could run fast enough to stop what was already happening at every other affected site.
Exam takeaways: (1) Logic bombs can be delivered as the payload of a Trojan installed via phishing. (2) The dormant period makes them nearly undetectable by AV before detonation. (3) Time-based logic bombs detonate on a schedule — no human action required at detonation. (4) MBR destruction renders systems unbootable. (5) Coordinated simultaneous detonation is designed to overwhelm incident response capacity.
On December 17, 2016, at 11:53 PM local time, parts of Ukraine lost power. The cause was a cyberattack on a high-voltage electrical substation — specifically, a logic bomb deployed against the SCADA systems controlling the substation's electrical circuits.
SCADA in power infrastructure: Supervisory Control and Data Acquisition (SCADA) systems are industrial control systems that monitor and control physical processes — in this case, the switching and management of high-voltage electrical circuits. SCADA interfaces bridge digital software commands with physical hardware actuators: a digital command to "open circuit breaker 14" translates into a physical action at the substation. An attacker who can issue commands to SCADA has direct control over the physical infrastructure.
The sophistication of the attack: This was not opportunistic malware. The attackers had spent significant time mapping the target organization's control network — understanding which SCADA systems were present, how they communicated, what their operational state was, and which circuits would cause maximum disruption when disabled. The malware was customized for this specific SCADA environment. Unlike generic malware, it contained knowledge of the target's specific systems.
The trigger: The timing — 11:53 PM, approaching midnight on December 17 — was deliberate. Minimal operational staffing at that hour. Maximum difficulty for emergency response. The specific date may also have been meaningful to the attackers. The detonation time was pre-programmed into the logic bomb.
The payload: At the trigger time, the malware began systematically disabling electrical circuits at the substation. The sequence had been pre-planned — the attackers' prior mapping of the control network told them which circuits to disable in what order for maximum effect. Areas of Ukraine lost power. Restoration required manual intervention at the physical substation, since the software control systems were compromised.
The physical-world consequence: This attack demonstrates the most significant distinction between SCADA-targeted attacks and typical cyberattacks. The payload was not data theft or system damage — it was physical-world disruption: loss of electrical power to populated areas. Attacks on SCADA-controlled water treatment could contaminate a water supply. Attacks on SCADA-controlled manufacturing could cause equipment failure or physical hazards.
Exam takeaways: (1) SCADA systems control physical infrastructure — attacks on them have real-world physical consequences, not just data loss. (2) Customized malware for a specific SCADA environment means no signatures exist. (3) Logic bombs targeting infrastructure can be pre-programmed for maximum operational disruption. (4) Detonation timing (midnight, specific dates) is chosen deliberately to maximize impact and minimize response capacity. (5) The Ukraine attack is the definitive exam example for SCADA-targeted logic bombs.
Scenario: A user reports that their banking credentials have been stolen. Investigation reveals that the user's computer has current antivirus with up-to-date signatures, uses HTTPS for all banking sessions, and has full-disk encryption enabled. No malware was found in the antivirus scan. However, a third-party anti-malware scan identifies a running process that hooks into the OS input subsystem and periodically writes to an encrypted outbound file. Which malware type is MOST consistent with these findings, and why did the antivirus miss it?
Answer: This is a keylogger. The indicators are: (1) credential theft despite HTTPS and full-disk encryption — keyloggers bypass these protections by capturing keystrokes before encryption is applied; (2) OS input subsystem hooking — keyloggers insert themselves into the OS input chain to intercept keystrokes; (3) periodic encrypted outbound file — the exfiltration mechanism for captured keystroke data; (4) clean standard AV scan — keyloggers frequently evade signature detection, particularly new or custom variants. The third-party anti-malware (different detection engine, behavioral analysis) caught what AV missed. The HTTPS and full-disk encryption provided zero protection because the keylogger captured credentials at the point of typing, before either protection applied.
Scenario: A systems administrator who managed a company's database servers was terminated with cause. Two weeks later, critical data in three production databases began being deleted nightly. Investigation reveals a scheduled database maintenance script that was present before the termination — but examination of the script's most recent version shows it includes an added section that executes nightly deletions. The script modification timestamp predates the administrator's last day of employment. What type of attack is this, what made it difficult to detect in advance, and what controls would have prevented or detected it earlier?
Answer: This is a logic bomb planted by an insider. Specifically, it is a time-based logic bomb embedded in an existing legitimate script. The characteristics are: (1) dormant until triggered — the modified script ran normally for two weeks before the deletion section executed (the attacker may have added a date-based condition); (2) embedded in legitimate infrastructure — using an existing scheduled script made the bomb harder to identify as new or suspicious; (3) no AV signature — custom code in a legitimate script context has nothing to match against.
Why it was difficult to detect: (1) The modification was to an existing script, not a new file — less likely to trigger attention. (2) During the dormant period, the script ran normally with no anomalous behavior. (3) Standard AV scans script files for known malware patterns, not for logic added to legitimate maintenance scripts.
Preventive controls: (1) File integrity monitoring — FIM/Tripwire would have detected the script modification immediately and alerted admins; (2) Formal change management — the script change should have required a documented change request; the unauthorized modification would have been visible; (3) Separation of duties — the DBA should not have been able to modify production maintenance scripts without review; (4) Offboarding procedures — review and audit of all systems and scripts touched by the departing admin before termination takes effect.
Scenario: A security analyst suspects a workstation has a rootkit infection. The antivirus scan returns clean. Task Manager shows no suspicious processes. However, network monitoring from the firewall logs shows the workstation making regular outbound connections to an unusual external IP address at 3:00 AM — connections that are not associated with any scheduled task or installed application the analyst can identify. What is the correct investigation approach and remediation sequence?
Answer: The clean AV scan and clean Task Manager output, combined with anomalous network connections that cannot be attributed to visible processes, is strongly consistent with a kernel-level rootkit. The rootkit is intercepting OS queries and hiding its process and network activity from both the antivirus and Task Manager. The firewall's external monitoring — which does not rely on the potentially compromised OS — shows the true activity.
Investigation approach: (1) Do not trust the live OS for investigation — it is potentially compromised. Boot from a trusted external forensic environment that does not use the installed OS's kernel. Examine the storage from that external environment; the rootkit cannot intercept queries from an OS it is not running in. (2) Look for kernel modifications, unusual driver files, or boot sector changes that would not be visible in the live OS. (3) If a specific rootkit variant is identified, use the rootkit-specific removal tool built for that variant.
Remediation: For a kernel rootkit, reimaging is the safest approach. Rootkits that have modified the kernel cannot be reliably removed in-place — the compromised OS cannot be trusted to execute or verify the removal. Wipe and reimage from a known-good baseline. Before reimaging, preserve a forensic image for analysis. After reimaging, enable Secure Boot to prevent recurrence — Secure Boot's signature verification at boot time will prevent a rootkit from modifying the kernel in the future.