48HOURS.

The impacted systems were all in the corporate head office in Leeds: finance workstations, two file servers, the HR shared drive. Files had been renamed with a .merlock extension. A ransom note had appeared on every desktop — a plain text file demanding 85 BTC, with a .onion address and a deadline of seventy-two hours. This is textbook ransomware: malware that encrypts the victim's data and withholds the decryption key until a payment is made. Ransomware does not hide. Its payload is the notification itself.

Riya's first call was containment. The affected subnet was isolated at the network layer. VPN access was suspended company-wide. Falcon was set to prevention mode on all remaining endpoints. Then she made the call that distinguishes a disciplined IR from a reactive one: she did not reimage the patient-zero machine. She isolated it, flagged it for memory acquisition, and moved to understand how the ransomware arrived.

The Falcon telemetry showed the encryption process had started at 02:51. But the timeline reconstruction in Splunk showed something else: lateral movement events across twelve internal hosts beginning at 01:17. The ransomware had not arrived and immediately detonated. It had arrived earlier, traversed the network, and triggered at a scheduled time. This meant it had not spread by someone clicking a file on fourteen machines simultaneously. It had propagated autonomously.

That behaviour has a name. A worm is malware that replicates and spreads across a network without requiring a host file or human action. Unlike a virus — which must attach itself to an existing executable and waits for that file to be opened before it can replicate — a worm finds its own path. The Splunk events showed SMBv1 traffic between hosts at timestamps consistent with automated scanning and exploitation. The worm had found open shares, copied itself, and executed remotely using scheduled tasks. Fourteen machines in ninety-four minutes, while the office was empty.

At 06:30, the memory forensics team ran Volatility against the patient-zero image. What they found under the ransomware was something older. A kernel-mode driver that should not have been there: an unsigned module loaded at boot, intercepting filesystem calls and hiding a directory under C:\Windows\System32\drivers\ from the standard Windows API. Standard tools saw nothing. Volatility's raw memory walk found it because it bypassed the OS API entirely and read physical memory directly.

This is textbook rootkit behaviour. A rootkit operates at or below the operating system layer — in kernel space, in firmware, or in the bootloader — and manipulates the OS's own reporting mechanisms so that standard tools cannot see it. The rootkit on patient zero had been resident since before the ransomware. It had not caused the encryption. It had been used to hide something else while that something else did its work. The investigation was now two incidents layered on top of each other.

Riya opened a second incident ticket. She wrote the time in the header and updated the scope: this is not a single ransomware event. This is a multi-stage intrusion.

The hidden directory the rootkit was protecting contained three executables. The DFIR team submitted all three to Any.Run for sandboxed detonation. The first was the worm dropper — the component that had replicated across the estate. The second was the ransomware encryptor itself. The third was something different: a process that was recording keystrokes and writing them to a local buffer, then exfiltrating that buffer over HTTPS to an external host every four hours.

A keylogger is a type of malware that captures every keystroke typed on the infected machine. It is a specific form of spyware — the broader category of malware whose purpose is intelligence gathering rather than disruption. Spyware watches what you do; a keylogger records exactly what you type. The distinction matters for the exam: all keyloggers are spyware, but not all spyware is a keylogger. VirusTotal returned a match on the third executable: SHA-256 hash corresponded to a known commodity keylogger family, first seen in the wild fourteen months earlier. The hash was the signature; detection here was signature-based.

The HTTPS exfiltration destination was a domain registered eight months ago. Splunk's DNS query logs showed the corporate network had been resolving that domain regularly since the same month the rootkit had been installed. Eight months of keystroke data had left the building. Finance credentials. Supplier login details. The managing director's email password, captured the day she typed it into the Outlook web client. The keylogger was not the attack; it was the reconnaissance that made the attack possible.

The Splunk analyst, Dev, found the initial access vector on Wednesday morning: a Windows installer package delivered via a procurement portal. Twelve months earlier, a supplier had uploaded a software update package to a shared partner portal. The update was legitimate on the surface — a genuine version bump of a scheduling tool used by the facilities team. The malicious payload was bundled inside it. When a facilities coordinator ran the installer, they installed the scheduling update and, without any visible sign, also dropped and executed the rootkit. This is the definition of a Trojan: malware disguised as legitimate software. The user consented to run what appeared to be a valid program. The malicious component was hidden inside it.

Wednesday afternoon produced the most unsettling finding of the investigation. A Defender for Endpoint alert on a distribution centre machine in Bristol showed a PowerShell process running from WINWORD.EXE's process tree. The command had been base64-encoded. Decoded, it downloaded a second-stage payload directly into memory and established a reverse shell to an attacker-controlled host. Falcon's process tree confirmed: no file had been written to disk. The payload lived entirely in RAM. When Dev rebooted the machine to confirm the process was gone, it was. Nothing to scan. Nothing to hash. Nothing to quarantine.

This is fileless malware: malicious code that executes entirely in memory, using legitimate OS components — PowerShell, WMI, the Windows Script Host — to carry out its actions without ever writing a file to disk. Traditional signature-based antivirus scans files. If there is no file, there is no scan. Detection requires behavioural analysis: watching what processes do rather than what files they have written. Falcon's behavioural engine caught it because it recognised the pattern of Word spawning an encoded PowerShell command with a network callback. The behaviour was the signature.

Dev correlated the Bristol machine's PowerShell event back through Splunk and found twelve similar events across six different endpoints over a three-week window. All had been missed by the installed AV. Only one had generated a Defender alert, and that alert had sat unacknowledged in the queue for nine days. The fileless malware had been providing the attacker with interactive access to internal systems while the rest of the intrusion developed around it. This interactive remote access capability — shell on demand, file browsing, credential harvesting through the live session — is the function of a backdoor: a persistent covert channel into a system that allows re-entry without re-exploitation. The fileless loader was establishing that backdoor fresh on each session; no persistence mechanism on disk meant the backdoor was re-established each time via a scheduled task that re-ran the loader.

Riya updated the incident timeline. The sequence was becoming clear. The Trojan installer had dropped the rootkit and keylogger twelve months ago. The keylogger had harvested credentials. Those credentials had been used to establish fileless backdoor sessions over the following months. The worm and ransomware were the final stage — the monetisation event at the end of a long, patient intrusion.

The Azure AD logs showed one more thing: an account that had not logged in for eleven months had authenticated from a Bulgarian IP address six weeks before the ransomware event. The account belonged to a member of the finance team who had left the company the previous year. This is the profile of a logic bomb — not in this case, but the pattern was structurally identical. A logic bomb is malicious code that remains dormant until a specific condition is met: a date, a system event, a user action. The dormant ex-employee account was the attacker's equivalent: a pre-positioned capability that activated only when they needed it. The Splunk team found the actual logic bomb in a scheduled task on the primary file server: a batch script that checked for a specific environment variable set by the worm on infection, and only executed the ransomware encryptor once that variable was present across a minimum of ten hosts. The ransomware had waited for confirmation that propagation was complete before detonating.

The Azure tenant review on Wednesday evening uncovered the final two components. One of the Bristol workstations was generating outbound HTTPS traffic to a mining pool at volumes far above normal. Falcon's network telemetry showed the traffic was coming from a legitimate-looking process, svchost.exe, with an unusual parent. Memory analysis confirmed: a cryptojacker had been installed alongside the fileless loader. A cryptojacker hijacks the host machine's CPU and GPU resources to mine cryptocurrency for the attacker, using the victim's electricity and hardware. It causes no data loss and leaves no ransom note, which is why it often runs undetected for months. The Mercer & Webb instances had been running for approximately nine weeks.

The final finding was the broadest in scope. The Splunk SIEM analyst found evidence of long-duration, low-volume outbound HTTPS connections from the head office proxy logs going back eleven months. The connections were to a legitimate-looking cloud storage provider. The User-Agent strings were slightly malformed — a tiny artefact that had never triggered a rule. Dev built a YARA rule against the malformed string pattern and ran it across eleven months of proxy logs. Hundreds of thousands of matching requests. The total estimated egress volume, calculated from byte counts in the proxy logs, was 4.3 gigabytes. This was spyware in its broadest operational form: a component that had been silently collecting and exfiltrating data from the corporate environment for almost a year. Not a keylogger in this instance — the module targeted specific file paths, screenshotted at intervals, and harvested browser session tokens. Data leaving continuously, slowly enough never to trigger a bandwidth threshold alert.

At 09:00 on Thursday, Riya opened the lessons-learned session. The incident timeline on the whiteboard ran from month minus twelve to hour zero. Eleven distinct malware types, two broad classification axes: how each one spreads, and what it does once it has arrived. The ransomware had been the loudest thing in the room. It had also been the last thing that happened.