Investigating a LockBit 2.0

Investigating a LockBit 2.0 Ransomware Attack: A Full DFIR Walkthrough on Meridian Financial Services

I'm Michael Oscar, a penetration tester and security researcher based in Lagos, Nigeria. This is a writeup of a Digital Forensics and Incident Response (DFIR) investigation I conducted on a simulated ransomware incident targeting a fictional financial institution Meridian Financial Services. The scenario was CTF-based, but every tool, command, and methodology used reflects real-world incident response practice.

This writeup covers the full investigation chain: evidence acquisition, network forensics, filesystem analysis, artifact recovery, and findings documentation. Whether you are new to DFIR or already working in security, there is something useful here.

The Scenario

Meridian Financial Services, a mid-sized financial institution, reported a full-scale ransomware incident. Systems were encrypted, operations were halted, and a ransom note had been deployed across affected endpoints. The threat actor: LockBit 2.0, a Ransomware-as-a-Service (RaaS) operation responsible for hundreds of confirmed attacks against financial, healthcare, and critical infrastructure targets before law enforcement action under Operation Cronos dismantled significant portions of their infrastructure in early 2024.

My objective was to conduct a forensic investigation of the compromised environment, reconstruct the attack timeline, identify threat actor TTPs (Tactics, Techniques, and Procedures), and produce an investigation report suitable for both technical teams and executive stakeholders.

Environment and Tools

Operating System: Kali Linux

Evidence Format: .E01 (Expert Witness Format) — the industry standard for forensic disk imaging. E01 preserves the exact byte-for-byte state of a disk while maintaining metadata like acquisition timestamps, hash verification, and case information.

Tools used throughout the investigation:

• ewfmount — mounts E01 images as read-only block devices, preserving forensic integrity
• tshark — command-line network protocol analyzer (Wireshark backend)
• pcapfix — repairs corrupted or truncated packet capture files
• Autopsy — open-source digital forensics platform for filesystem analysis and artifact recovery
• Manual log analysis and cross-referencing via terminal

One principle that governed every step: never modify the original evidence. All analysis was performed on mounted read-only images or working copies. This preserves chain of custody — a non-negotiable requirement in any forensic investigation, simulated or otherwise.

Phase 1: Evidence Acquisition and Mounting

The first task was mounting the E01 disk image without altering it.

sudo mkdir /mnt/ewf
sudo ewfmount meridian_disk.E01 /mnt/ewf

sudo mkdir /mnt/ewf
sudo ewfmount meridian_disk.E01 /mnt/ewf

Once mounted, the image appeared as a virtual block device. From there, the filesystem partitions were accessible for analysis without any risk of write operations touching the original image.

Hash verification was performed before and after mounting to confirm evidence integrity — standard practice when evidence may eventually be presented in a legal or compliance context.

Phase 2: Network Forensics

Before touching the filesystem, I focused on the network capture files. Understanding what happened on the wire before and during encryption is critical — it often reveals the attacker's entry point, lateral movement paths, and exfiltration activity.

The PCAP file pulled from the environment was corrupted — a common problem in incident scenarios where systems are abruptly shut down mid-capture. pcapfix was used to recover it:

pcapfix captured_traffic.pcap -o recovered_traffic.pcap

pcapfix captured_traffic.pcap -o recovered_traffic.pcap

With a clean capture file, analysis moved to tshark. The first priority was identifying unusual outbound connections.

tshark -r recovered_traffic.pcap -Y "tcp" -T fields -e ip.src -e ip.dst -e tcp.dstport | sort | uniq -c | sort -rn

tshark -r recovered_traffic.pcap -Y "tcp" -T fields -e ip.src -e ip.dst -e tcp.dstport | sort | uniq -c | sort -rn

Findings from network analysis:

C2 Beaconing — Consistent outbound connections to external IPs at regular intervals, characteristic of Command and Control communication. LockBit affiliates commonly use HTTP/S-based C2 frameworks (Cobalt Strike, Metasploit, custom loaders) to maintain persistent access prior to deploying the ransomware payload.

Pre-encryption Data Exfiltration — Significant outbound data transfer volumes were recorded in the hours preceding encryption. LockBit 2.0 operates a double-extortion model: data is exfiltrated first, then encrypted. The threat of public data release on LockBit's leak site is used as additional leverage alongside the encryption ransom.

Lateral Movement Traffic — SMB and RPC traffic between internal hosts indicated the attacker had already moved through the network before the encryption event. This is consistent with LockBit's documented behavior — affiliates typically spend time inside a network conducting reconnaissance and spreading access before triggering the payload.

Phase 3: Filesystem Analysis and Artifact Recovery

With the network picture established, investigation shifted to the filesystem.

Opening the mounted image in Autopsy allowed timeline analysis, deleted file recovery, and artifact correlation. Key areas of focus:

Encrypted File Artifacts

Directories across the filesystem showed mass file renaming consistent with LockBit 2.0's encryption pattern. LockBit appends its own extension to every encrypted file and drops a ransom note (Restore-My-Files.txt) into every affected directory. Both were confirmed across multiple partitions.

Windows Event Log Analysis

Event logs were partially wiped — a deliberate anti-forensic action. LockBit affiliates routinely clear Security, System, and Application logs to hinder investigation. However, partial log recovery was possible, and cross-referencing recovered entries with the network timeline helped fill gaps in the attack sequence.

Relevant Event IDs reviewed:

• 4624 / 4625 — Logon success and failure events (identifying brute force or credential use)
• 7045 — New service installation (common persistence mechanism)
• 4697 — Service installed in the system (overlaps with 7045, useful for cross-reference)
• 1102 — Audit log cleared (confirms the anti-forensic activity)

Prefetch and Registry Artifacts

Prefetch files confirmed execution of suspicious binaries in the hours preceding the encryption event. Registry analysis revealed persistence mechanisms consistent with RaaS affiliate toolkits — scheduled tasks and run keys pointing to executables that were no longer present on disk (deleted post-execution, another common anti-forensic step).

Phase 4: Attack Timeline Reconstruction

Correlating network captures with filesystem timestamps and recovered log entries produced the following attack sequence:

Time (Relative) Activity T-72h Initial access — likely phishing or exposed RDP (entry point not conclusively confirmed from available evidence) T-48h C2 beacon traffic begins — persistent outbound connections established T-24h Lateral movement across internal hosts via SMB T-6h Mass data exfiltration to external IPs T-1h Event log clearing — attacker begins anti-forensic activity T-0 Ransomware payload deployed — mass encryption, ransom notes dropped

The gap between initial access and payload deployment (approximately 72 hours) is consistent with documented LockBit affiliate behavior. Affiliates do not immediately encrypt — they conduct internal reconnaissance, identify high-value targets, maximize spread, and exfiltrate data before triggering the payload.

Key Findings Summary

Category Finding Network C2 beaconing confirmed pre-encryption; data exfiltration volume significant Filesystem Mass encryption with LockBit extension; ransom note in all affected directories Event Logs Partial wipe confirmed (Event ID 1102); partial recovery achieved Persistence Registry run keys and scheduled tasks pointing to deleted executables Anti-Forensics Log clearing, file deletion post-execution Exfiltration Double-extortion model confirmed — data exfil before encryption

MITRE ATT&CK Mapping

LockBit 2.0 TTPs observed in this investigation map to the following techniques:

• T1566 — Phishing (Initial Access)
• T1021.002 — SMB/Windows Admin Shares (Lateral Movement)
• T1041 — Exfiltration Over C2 Channel
• T1490 — Inhibit System Recovery
• T1070.001 — Clear Windows Event Logs (Defense Evasion)
• T1486 — Data Encrypted for Impact

What This Investigation Demonstrates

A few things became clear working through this scenario that apply beyond CTF environments:

Corrupted evidence is not lost evidence. The PCAP file in this case was unreadable out of the box. Without pcapfix, a significant portion of the network forensics picture would have been missing. In real incidents, evidence is rarely clean — systems crash, storage fails, logs get wiped. Recovery methodology matters.

The network timeline anchors everything. Filesystem timestamps can be manipulated. Log entries can be deleted. Network captures, when available, are significantly harder for attackers to retroactively alter — especially when the captures originate from network infrastructure the attacker does not control (firewalls, network taps, cloud flow logs). Always start with the wire.

Anti-forensic activity is itself a finding. The attacker clearing event logs is evidence. The absence of logs where logs should exist is an artifact. Documenting what was deleted, when, and what partial data was recovered is as important as documenting what was found intact.

Full Report

The complete investigation report including all documented artifacts, tool commands, findings, and recommendationsis published on GitHub:

https://github.com/michspenz/Ransomware-DFIR-Investigation