Why keyloggers defeat HTTPS and full-disk encryption; what else they collect beyond keystrokes; how logic bombs remain invisible until they detonate; the real attacks in South Korea and Ukraine; why rootkits are invisible to Task Manager and traditional antivirus; and how Secure Boot stops them at the hardware level.
Scene 1 — The Keystroke Is Always in the Clear
Yusuf, senior digital forensics examiner at a regional cybersecurity firm, often used one slide to open his client briefings. It showed a padlock — the HTTPS icon — and a keyboard. He called it "the gap."
"Your organization has HTTPS on every web application," he would say. "Your laptops have full-disk encryption. Your email is encrypted in transit. Everything between your computer and the server is protected. But here's the gap." He would point to the keyboard on the slide. "Before any of that encryption happens, your users typed something. That something — the username, the password, the credit card number — was plaintext at the moment it left their fingertips. That's where a keylogger lives."
A keylogger is malware designed to capture every keystroke typed on a device. It installs itself and runs invisibly in the background, recording input continuously. Once or multiple times per day, it packages everything recorded and sends that file to the attacker's server. The attacker now has a transcript of everything the user typed: login credentials, banking details, internal document contents, private messages.
The critical insight — the one Yusuf emphasized in every briefing — is that keyloggers circumvent encryption. The moment a user types a password into a browser login field, that password exists as plaintext keystrokes before the browser encrypts it for transmission. The browser's HTTPS connection encrypts the data for the network journey. The full-disk encryption protects the data if the hard drive is stolen. Neither does anything about the keystrokes. The keylogger captures those keystrokes before either protection layer can act.
Encryption protects data in transit (HTTPS) and data at rest (full-disk encryption). A keylogger operates between the keyboard and the application — it captures the raw input before the application ever processes it. There is no encryption layer that covers the act of typing.
Yusuf had been called in on a case involving a mid-size logistics company. A finance employee's credentials had been used to authorize three fraudulent wire transfers over two weeks. The employee insisted she had not made those transfers, had not shared her password, and had not clicked anything suspicious.
Yusuf imaged the employee's laptop and found it. A lightweight keylogger had been installed — the forensic timestamp showed it had arrived nine days before the first fraudulent transfer, bundled with a free font package the employee had downloaded to make her presentation slides look better. The keylogger had been recording silently for nine days before it was used. The collected file, sent nightly to an external server, contained the employee's banking portal login, her email password, and her VPN credentials.
"The encryption your bank uses between your browser and their server is completely intact," Yusuf told the client. "The attacker never touched that. They didn't need to. They had her password before she finished typing it."
Scene 2 — Beyond Keystrokes: What a Modern Keylogger Captures
After the logistics company engagement, Yusuf gave a presentation to a group of IT managers. He wanted to expand their understanding of what keyloggers actually collect — because most people thought of keyloggers as only capturing passwords.
"Think about a full day on your computer," he said. "You type — obviously. But what else do you do?" He walked through the list.
Clipboard logging: Users constantly copy and paste. A password manager might have the user copy a password from the manager and paste it into a login field — never actually typing it on the keyboard. A keylogger with clipboard monitoring captures whatever is in the clipboard, including that copied password.
Screen logging: Keyloggers can take periodic screenshots. Every thirty seconds, a screenshot. The attacker's server receives a visual timeline of everything on the user's screen throughout the day — documents being read, emails being composed, web pages being visited.
Instant messaging and chat monitoring: Messages typed in chat applications are captured. For a corporate environment where sensitive business decisions are discussed in Slack or Teams, this is a significant data exposure beyond just login credentials.
Search engine query logging: Every search term typed into a search engine is captured. A user researching an acquisition target, a medical condition, a legal matter, or a personal concern — all of that becomes part of the attacker's data file.
Yusuf then showed a screenshot from a tool called DarkComet. DarkComet is a Remote Access Trojan — a RAT — that includes a full keylogger module as one of its capabilities. He had used it in a controlled lab environment to demonstrate.
"In the demo," he explained, "I typed 'username: professormesser' and 'password: notarealpassword' into a Notepad file. The DarkComet keylogger captured not just the characters — it captured the exact sequence, including the fact that I typed a space and then pressed Delete to correct a typo. It knew when I typed each character. That level of detail is what the attacker receives. Every credential. Every correction. Every pause."
DarkComet RAT is a real tool that combines keylogging, screenshots, clipboard monitoring, and remote access in a single package. It demonstrates that keyloggers are not primitive one-trick tools — they are comprehensive surveillance platforms. The attacker's log is a complete record of the user's session, not just a list of passwords.
The defense against keyloggers is not simple. Multi-factor authentication helps — stealing the password alone is not enough to log in if the second factor is a physical token or an authenticator app that cannot be keylogged. Running dedicated anti-malware tools (not just standard antivirus) improves detection odds because anti-malware specifically targets surveillance behaviors. And avoiding risky installation vectors — free software from third-party sites, P2P downloads — reduces the chance of getting one in the first place.
Scene 3 — The Bomb That Was Already There
Three months later, Yusuf received a call from the HR director of a financial services firm. A senior network administrator — call him Dakarai — had been terminated for cause. Two days after the termination, a scheduled task began deleting backup files from the firm's primary file server. By the time IT noticed, six weeks of backups had been quietly removed.
Yusuf knew what he was looking at before he arrived on site. "This is a logic bomb," he told the HR director over the phone. "It was planted before he left. It was waiting."
A logic bomb is malicious code that remains completely dormant until a specific trigger condition is met. Before the trigger fires, it does nothing — no unusual network traffic, no anomalous process activity, nothing to detect. When the trigger fires, the payload executes.
Triggers fall into two categories. A time bomb triggers on a specific date, time, or recurring schedule — "execute at 2:00 PM on March 20th" or "run every Sunday at midnight." A user-event logic bomb triggers on a system event — "execute when user account 'dakarai_admin' is disabled" or "execute when this file is opened." In Dakarai's case, the scheduled task was set to run beginning on the date of his termination — a time bomb with a specific starting date.
"What makes logic bombs so dangerous," Yusuf explained to the client's security team, "is that they're custom. Each one is written for the specific environment where it will be detonated. It's not malware that was used in a thousand other attacks. It doesn't match any signature in any antivirus database. You cannot scan for it with a virus definition update because there is no definition. It was created specifically for you."
Traditional antivirus uses signature-based detection — matching files against a database of known malware patterns. A logic bomb is custom code written for one specific environment. It has never been analyzed, classified, or added to any signature database. The antivirus engine has nothing to compare it to. This is why process controls — not detection tools — are the primary defense.
Dakarai had planted the logic bomb on his last day of employment. As a network administrator, he had the access to place a scheduled task that would not run until days after he was gone. By the time the damage began, he was three days into a new job and would claim he knew nothing about it.
The investigation found the planted scheduled task in the Windows Task Scheduler on two servers. The task script called a PowerShell command to recursively delete files in specific backup directories. Had the firm been running file integrity monitoring software — which would alert when critical system configurations or scheduled tasks changed — the task placement might have been detected the day it was created.
"You caught this because someone noticed the backups were gone," Yusuf told the team. "In a worse version of this story, the attacker waits six months, the backups quietly disappear, and you don't find out until a ransomware attack hits and you try to restore from a backup that doesn't exist."
Scene 4 — When the Bomb Was for a Nation
Logic bombs in the hands of a sophisticated threat actor — or a nation-state — operate at an entirely different scale. Yusuf used two real incidents in his training materials.
South Korea, March 2013. Banks and broadcasting companies in South Korea received phishing emails carrying malicious attachments that appeared to come from legitimate financial institutions. Users who opened the attachments installed a Trojan. The Trojan carried a time-based logic bomb set to activate twenty-four hours later, on March 20, 2013, at 2:00 PM local time.
At exactly 2:00 PM, the logic bomb activated on every infected system simultaneously. It deleted the storage contents and the Master Boot Record — the critical sector of the hard disk that tells the computer how to load the operating system. The systems rebooted. With no MBR, there was no operating system to start. Thousands of screens displayed: "Boot device not found. Please install an operating system on your hard disk."
The bank's ATMs were included. At 2:00 PM, ATMs across South Korea became unusable. Customers who tried to withdraw money saw the same error message. The coordinated simultaneous detonation across thousands of systems was the logic bomb's design advantage — no manual trigger, no human operator present, perfectly synchronized.
Ukraine, December 17, 2016. This attack was more targeted and technically sophisticated. Attackers had spent months mapping a Ukrainian electrical utility's control network. The malware they deployed was specifically engineered for SCADA systems — Supervisory Control and Data Acquisition systems that manage industrial control of physical infrastructure like power grids, water treatment, and manufacturing.
At 11:53 PM on December 17, the logic bomb triggered. The malware began systematically disabling electrical circuits at a high-voltage substation. The attackers had mapped out which circuits to disable in what order to maximize disruption. The detonation time — approaching midnight — was chosen deliberately: minimal staffing, maximum response difficulty. Parts of Ukraine lost power.
SCADA systems control physical processes in critical infrastructure. When a logic bomb targets SCADA, the payload is not data deletion — it is physical-world disruption. Disabling an electrical substation's circuits, contaminating a water supply, or stopping a manufacturing line are all within the scope of SCADA-targeted malware. The Ukraine attack demonstrated that logic bombs can be weaponized against physical infrastructure with real-world consequences.
"The South Korea attack was a time bomb," Yusuf would explain. "The Ukraine attack was more sophisticated — it was mapped to the specific operational state of the SCADA network. The attackers understood the target's infrastructure deeply enough to write custom malware that knew which circuits to disable. That's not opportunistic malware. That's a custom-built weapon aimed at a specific system."
The controls against logic bombs are procedural, not technological. Formal change management — every modification to critical systems documented, reviewed, and approved before implementation — limits the ability of insiders to plant bombs undetected. File integrity monitoring tools like Tripwire alert when critical files or system configurations change unexpectedly. Host-based intrusion detection systems watch for anomalous behavior. And separation of duties ensures that no single person has both the access and the opportunity to plant and arm a bomb without oversight.
Scene 5 — The Malware That Lives Inside the Operating System
At a forensics conference, a colleague asked Yusuf: "What's the hardest malware to find?" He answered without hesitation: "A well-written rootkit."
A rootkit takes its name from Unix systems, where the highest-privilege account is called root — the equivalent of Administrator on Windows. A rootkit achieves root-level access and then buries itself where that access allows it to hide: inside the operating system kernel.
The kernel is the core of the operating system — the software that sits between applications and hardware, managing memory, processes, and access to system resources. When a rootkit embeds itself in the kernel, it becomes part of the OS itself. It is not a process running on top of the OS. It is woven into the OS.
"Think about what that means practically," Yusuf explained. "When you open Task Manager to see what processes are running, Task Manager asks the operating system for a list of processes. If the rootkit is inside the operating system, it can intercept that request and remove itself from the list before Task Manager displays it. You see every process except the rootkit. You cannot see something that controls the information you use to look for it."
The same principle applies to antivirus software. Traditional antivirus scans files and running processes by asking the operating system what is present. A rootkit that has embedded itself in the kernel can hide its own files and processes from those queries. The antivirus asks the OS: "What files are here?" The OS — compromised by the rootkit — answers with a list that excludes the rootkit's components. The scan completes. Nothing found.
Antivirus queries the operating system for information about running processes and files. A kernel rootkit operates inside the OS — it can intercept and falsify those query results. The antivirus gets back a list that omits the rootkit. Detection requires either running the OS from a trusted external source (so the compromised OS is not queried) or using rootkit-specific tools that use their own detection methods.
Not every rootkit operates at the kernel level. Some run as elevated processes in user space and can be detected by anti-malware software if the detection engine is not also relying on a compromised OS layer. But kernel rootkits are the genuinely difficult cases.
When Yusuf suspected a rootkit, his first step was never to scan the live system. He would boot from a trusted external drive — a forensic boot environment — so that the potentially compromised OS was never the one answering queries. From that external environment, he could examine the system's storage directly, without the rootkit's ability to intercept or falsify what he saw.
If a specific rootkit variant was identified, he would use a rootkit removal tool built specifically for that variant. These tools were created after the rootkit was discovered and analyzed by security researchers — meaning they knew exactly what the rootkit had modified and could reverse those modifications precisely. The downside: these tools are retrospective. They are built after discovery, not before. They cannot prevent infection; they can only clean up afterward.
The preventive answer is Secure Boot — a feature in modern UEFI BIOS firmware. Secure Boot works at the hardware level, before the operating system loads. When the computer powers on, Secure Boot verifies the digital signature of every component that is about to load as part of the OS startup sequence. If any component's signature does not match a trusted key — if the kernel has been modified by a rootkit — Secure Boot stops the boot process. The rootkit cannot load. The system is protected before the OS even starts.
"Secure Boot is the answer to 'how do you stop something that hides inside the OS?'" Yusuf told his conference audience. "You stop it before it gets to run. You check the OS's integrity before you let it boot. If the rootkit has modified the kernel, the signature won't match, and the system refuses to start that kernel. The rootkit never gets to run."
Secure Boot is a UEFI BIOS feature that verifies the digital signature of OS components before loading them. If a rootkit has modified the kernel, the signature check fails and the system will not boot that modified OS. This prevents rootkits from running — but it requires that Secure Boot is enabled and that the trusted keys are properly configured.
Yusuf ended the conference session with a summary that he believed captured what made these three malware types the hardest to defend against.
"Keyloggers win by attacking the one moment that no encryption can cover — the moment you type. Logic bombs win by waiting — the longer they wait, the more access they accumulate, and the more damage they can do when they finally trigger. Rootkits win by hiding inside the thing you use to look for them. Each of these is a different kind of difficult. None of them can be answered by just buying better antivirus. They require architecture decisions, process controls, and hardware-level protections — the kind of security that has to be designed in from the beginning, not bolted on after something goes wrong."