Incident Response 103: Ransomware Response: So Someone Encrypted Everything

Series: Incident Response | Reading time: ~15 minutes | Author: Tech Corsair

Introduction: Deep Breaths, Everyone

It is 6:47am on a Monday. The helpdesk phone is already ringing. File shares are inaccessible. Desktop wallpapers have been replaced with a cheerful ransom note in broken English. Someone in Finance is crying. Someone in IT is quietly updating their LinkedIn profile. The CEO is on the phone demanding to know "how this happened" and "why we pay so much for cybersecurity."

Welcome to ransomware response. The good news is that this is a survivable event. The bad news is that "survivable" and "pleasant" are different words for a reason.

Panicking has never decrypted a single file. What follows is a structured approach to ransomware incident response -- from initial discovery through to root cause analysis and data exfiltration assessment. It is not a guarantee of a happy ending, but it is a great deal better than the alternative, which typically involves a lot of running about and shouting.

Phase 1: Initial Assessment -- "How Bad Is It?"

The first thirty minutes of a ransomware incident set the tone for the entire response. The priority is to understand the scope before taking action that might make things worse.

Immediate Actions

1. Do not shut down encrypted systems.

The instinct is to pull power cables. Resist it. Encrypted systems may still contain:

• Ransomware encryption keys in memory (some variants keep them until reboot)
• Evidence of the attacker's tools and techniques
• Indicators of how far the encryption has spread

Shutting down systems destroys volatile evidence. It does not undo encryption. The damage is already done -- the evidence does not need to join it.

2. Isolate, do not eradicate.

Disconnect affected systems from the network. Disable Wi-Fi adapters. Shut down switch ports. Use EDR network isolation if available. The goal is to stop the encryption from spreading to unaffected systems without destroying evidence on already-affected ones.

3. Identify the ransomware variant.

The ransom note, the file extension applied to encrypted files, and the content of any dropped files can identify the variant. Resources such as ID Ransomware (id-ransomware.malwarehunterteam.com) and No More Ransom (nomoreransom.org) can help. Why does this matter? Because:

• Some variants have known decryptors. Free decryption may be available.
• The variant identifies the threat actor group, which reveals likely TTPs, dwell time, and whether data exfiltration is probable.
• Knowing the variant informs whether the attacker is likely still in the network (spoiler: they often are).

4. Assess the blast radius.

• How many endpoints are encrypted?
• Are servers affected? Which ones?
• Are domain controllers compromised? (If so, the situation has escalated significantly.)
• Are backups intact? Can the backup infrastructure be reached? Is it encrypted too?
• Are cloud services affected?

The Stakeholder Call

Within the first hour, key stakeholders need to be informed:

• Executive leadership: The business is impacted. They need to know.
• Legal counsel: Regulatory obligations may be triggered. The clock starts ticking.
• Cyber insurance provider: Most policies have notification requirements within specific timeframes. Missing these can void coverage, which adds financial injury to digital insult.
• DFIR retainer (if available): Activate the retainer. The earlier forensic experts are engaged, the better the outcome.
• Law enforcement: Reporting to the relevant authorities (NCA/NCSC in the UK, FBI/CISA in the US) is recommended. They may have intelligence on the threat actor, including decryption keys.

Phase 2: Finding Patient Zero -- "Where Did This Start?"

Identifying the initial point of compromise is critical for two reasons: it tells responders how the attacker got in (so the door can be closed), and it reveals how long the attacker has been in the network (the "dwell time"), which directly impacts the scope of the investigation.

The Two Origin Stories

Ransomware deployments generally arrive via one of two paths:

Path A: The Malware Chain

A multi-stage infection chain where each component downloads the next:

Phishing email -> Malicious document -> Emotet/QakBot/IcedID
-> Cobalt Strike / Sliver beacon -> Lateral movement
-> Domain compromise -> Ransomware deployment

The classic example was the Emotet to TrickBot to Ryuk chain, though the specific malware families rotate. The pattern remains: initial access broker gains a foothold, sells or passes access to a ransomware operator, who then spends days or weeks moving laterally before deploying encryption.

Dwell time in these cases is typically 3-14 days, though it can be longer. The attacker uses this time for reconnaissance, privilege escalation, data exfiltration, and positioning for maximum impact.

Path B: The Brute-Force Entry

Direct compromise of an internet-facing service:

Exposed RDP / VPN / Citrix -> Brute-force or credential stuffing
-> Valid account access -> Lateral movement
-> Domain compromise -> Ransomware deployment

This path is depressingly common. Exposed Remote Desktop Protocol (RDP) with weak credentials remains one of the most frequent initial access vectors for ransomware. The attacker simply logs in with valid credentials, no malware chain required.

Dwell time for brute-force entry is typically shorter -- hours to a few days -- because the attacker already has valid credentials and does not need to establish a complex toolchain.

The Investigation Trail: Working Backwards from Encryption

The investigation starts with what is known (encrypted systems) and works backwards to what is not known (initial access).

Step 1: Event ID 7045 -- Service Installation

Ransomware is frequently deployed via PsExec or similar remote execution tools that install a service on the target system. Windows Security Event ID 7045 (A service was installed in the system) recorded in the System event log is the first breadcrumb.

On encrypted systems where event logs are still accessible (they usually are -- most ransomware encrypts user data, not system files), filter the System log for Event ID 7045 entries in the hours preceding encryption:

wevtutil qe System /q:"*[System[(EventID=7045)]]" /f:text

Look for:

• Services with random or suspicious names
• Services running executables from unusual paths (e.g., C:\Windows\Temp\, C:\PerfLogs\)
• Services installed using PsExec (service name: PSEXESVC)
• Services installed close together across multiple systems (indicating automated deployment)

Step 2: Event ID 4624 -- Logon Tracing

Once the deployment mechanism is identified, trace the account used for deployment. Windows Security Event ID 4624 (An account was successfully logged on) reveals:

• Logon Type 3 (Network): The account used for remote service installation
• Logon Type 10 (RemoteInteractive): RDP sessions
• Source Network Address: The system from which the logon originated

By following the Logon Type 3 events backwards -- from encrypted endpoint to the system that deployed the ransomware, from that system to the system before it -- the investigation team can trace the lateral movement path back to Patient Zero.

Step 3: Identifying Initial Access

On Patient Zero, the investigation pivots to identifying the initial access vector:

• Phishing: Check email logs for the user account. Look for malicious attachments or links in the days/weeks before the incident. Check browser history for payload download indicators.
• RDP brute-force: Check Event ID 4625 (Failed logon) for patterns of failed authentication attempts preceding a successful logon (4624 Logon Type 10). Check the source IP against threat intelligence feeds.
• VPN compromise: Check VPN authentication logs for anomalous logons -- unusual times, unusual source countries, successful logon after a series of failures.
• Exploited vulnerability: Check for known vulnerabilities in internet-facing services. Cross-reference patch levels with published exploits.

Timeline Reconstruction

Building a comprehensive timeline is essential. Tools like Plaso/log2timeline can ingest multiple evidence sources (event logs, file system timestamps, registry hives, browser history, prefetch files) and produce a unified, chronological timeline of activity. This timeline is the foundation for understanding the full scope of the compromise.

Phase 3: Triage Data Collection with KAPE

When hundreds of endpoints are potentially compromised, performing full forensic imaging of every system is neither practical nor necessary. This is where triage collection tools become essential.

KAPE (Kroll Artifact Parser and Extractor)

KAPE is the industry-standard tool for rapid triage collection. It collects forensic artefacts -- event logs, registry hives, prefetch files, browser history, $MFT, and dozens of other evidence sources -- without creating a full disk image. A KAPE collection that takes minutes provides 80-90% of the forensic evidence that a full disk image would, at a fraction of the time and storage cost.

Key KAPE Targets for Ransomware Investigation

• Event Logs: All .evtx files from C:\Windows\System32\winevt\Logs\
• Registry Hives: SAM, SYSTEM, SOFTWARE, SECURITY, NTUSER.DAT, UsrClass.dat
• Prefetch Files: Evidence of program execution from C:\Windows\Prefetch\
• $MFT: The NTFS Master File Table -- contains file creation and modification timestamps for every file, including deleted ones
• Amcache: Application compatibility cache -- records of program execution
• ShimCache: AppCompatCache -- another record of program execution
• SRUM (System Resource Usage Monitor): Network usage per application -- invaluable for identifying data exfiltration
• PowerShell History: ConsoleHost_history.txt for each user profile
• Scheduled Tasks: XML files from C:\Windows\System32\Tasks\
• Startup Items: Registry run keys, startup folder contents
• Browser History and Downloads: Evidence of payload downloads or exfiltration tool installation

Deploying KAPE at Scale

For large environments, KAPE can be deployed remotely via:

• EDR console push: Most EDR platforms support pushing and executing binaries on managed endpoints
• PsExec / WMIC / WinRM: Remote execution from a central management system
• SCCM / Intune / GPO: For environments with existing management infrastructure
• Velociraptor: An open-source endpoint monitoring and forensic tool that excels at large-scale evidence collection

The output is centralised for analysis, enabling the investigation team to process evidence from hundreds of endpoints in parallel.

Phase 4: Data Exfiltration Assessment -- "Did They Take Anything?"

Modern ransomware operations are almost universally "double extortion" -- the attacker encrypts the data and exfiltrates it, threatening to publish it if the ransom is not paid. Assessing whether data exfiltration occurred is therefore a critical component of ransomware response, with direct implications for regulatory notification obligations.

Common Exfiltration Tools and Their Artefacts

Threat actors are remarkably consistent in their choice of exfiltration tools. Identifying the artefacts of these tools can confirm or rule out data theft.

MEGAsync

The desktop client for the MEGA cloud storage service. Heavily favoured by ransomware operators because MEGA offers generous free storage, encrypted transfers, and is not blocked by most organisations' web filtering.

Artefacts:

• Installation records in %ProgramFiles%\MEGAsync\
• Prefetch files: MEGASYNC.EXE-*.pf
• SRUM database entries showing large upload volumes
• Registry entries under HKCU\Software\Mega Limited\MEGAsync
• MEGAsync.log file containing synchronisation details, including folder paths and file counts
• Network connections to *.mega.co.nz in proxy/firewall logs

rClone

A command-line tool for managing cloud storage. Legitimate tool, widely abused for data exfiltration because it supports virtually every cloud storage provider and can be configured to upload at high speed.

Artefacts:

• Often renamed to avoid detection (e.g., svchost.exe, svhost.exe, backup.exe). Check file hashes, not just names.
• Configuration file (rclone.conf) contains the cloud storage provider, access keys, and target bucket/container. This is a gold mine of evidence -- it reveals where the data was sent.
• Prefetch files for the renamed executable
• Command-line arguments in process creation logs (Sysmon Event ID 1 or Security Event ID 4688): look for rclone copy, rclone sync, --transfers, --bwlimit
• SRUM entries showing massive upload data for the process

Total Commander

A file manager with built-in FTP/SFTP capability. Used by some threat actor groups (notably Conti/Royal lineage) for browsing network shares and staging data for exfiltration.

Artefacts:

• Installation in %ProgramFiles%\totalcmd\ or portable execution
• totalcmd.ini and wcx_ftp.ini -- FTP server configuration, including target servers
• wincmd.ini -- general configuration including recent directory paths
• FTP log files showing upload activity
• Prefetch files: TOTALCMD.EXE-.pf or TOTALCMD64.EXE-.pf

WinSCP

An SFTP/FTP client for Windows. Another legitimate tool repurposed for exfiltration.

Artefacts:

• Registry entries under HKCU\Software\Martin Prikryl\WinSCP 2\
• WinSCP.ini configuration file with server details
• XML session logs if logging was enabled
• Prefetch files: WINSCP.EXE-*.pf

7-Zip / WinRAR

Data is typically staged (compressed into archives) before exfiltration. Large archive files in unusual locations (e.g., C:\PerfLogs\, C:\Windows\Temp\, shared drives) are suspicious.

Artefacts:

• Prefetch files for 7z.exe, 7zG.exe, rar.exe, winrar.exe
• Command-line arguments showing compression targets: 7z a -p archive.7z C:\Shares\Finance\*
• File system artefacts: large .7z, .zip, or .rar files in staging directories
• $MFT entries for archive files that have been deleted after exfiltration

Network-Based Exfiltration Indicators

Endpoint artefacts should be correlated with network evidence:

• Proxy logs: Large HTTP/HTTPS uploads to cloud storage providers
• Firewall logs: Sustained outbound connections with high data transfer volumes
• NetFlow data: Anomalous outbound data volumes from specific internal IPs
• DNS logs: Resolution of cloud storage domains (mega.co.nz, .amazonaws.com, .blob.core.windows.net) from systems that should not be using them

SRUM -- The Unsung Hero

The System Resource Usage Monitor (SRUM) database (C:\Windows\System32\sru\SRUDB.dat) records network usage per application over the past 30-60 days. It can reveal:

• Which applications sent large volumes of data
• The network interface used
• Timestamps of the activity

SRUM frequently survives ransomware encryption (it is a system file in a protected location) and can provide definitive evidence of data exfiltration even when other artefacts have been destroyed. Tools like SrumECmd (part of Eric Zimmerman's toolset) parse the SRUM database into usable output.

Phase 5: Containment and Recovery

With the scope understood, Patient Zero identified, and data exfiltration assessed, the response shifts to containment and recovery.

Immediate Containment

• Reset the krbtgt account password twice. If the attacker achieved domain admin access, they may have created a Golden Ticket. Resetting the krbtgt password twice (with a 12-hour gap between resets to allow replication) invalidates all existing Kerberos tickets.
• Reset all privileged account passwords. Domain admins, service accounts, local admin accounts. All of them.
• Disable compromised accounts. Any account used by the attacker should be disabled pending credential reset.
• Block known IOCs at the perimeter. C2 domains, IP addresses, and malicious file hashes identified during the investigation.
• Deploy EDR to all systems if not already present. This provides both detection capability and the ability to remotely isolate systems if the attacker returns.

Recovery Priorities

1. Verify backup integrity. Before restoring anything, confirm that backups are clean and accessible. Test restoration in an isolated environment.
2. Rebuild domain controllers from scratch if they were compromised. Do not restore compromised DCs from backup -- the compromise may be embedded in the Active Directory database.
3. Restore critical systems first. Prioritise based on business impact: email, core business applications, file services.
4. Monitor restored systems intensively. The attacker may have left persistence mechanisms that survived the rebuild. Enhanced logging and monitoring for the first 30-90 days post-recovery is essential.
5. Patch the initial access vector. Close whatever door the attacker came through. If it was exposed RDP, it should have been closed years ago, but better late than never. If it was a phishing email, review email filtering rules and conduct targeted awareness training.

---

The Ransom Question: To Pay or Not to Pay

This article deliberately does not advise on whether to pay the ransom. That decision involves legal, business, ethical, and regulatory considerations that are well beyond the scope of a technical playbook. What can be said:

• Paying does not guarantee data recovery. Some decryptors are poorly written and corrupt data during decryption.
• Paying does not guarantee data deletion. The attacker's promise to delete exfiltrated data is exactly as trustworthy as one would expect from a criminal enterprise.
• Paying may violate sanctions. If the threat actor group is on a sanctions list (OFAC in the US, UK/EU equivalent), paying the ransom may be a criminal offence.
• Not paying may mean permanent data loss if backups are unavailable or also encrypted.

Legal counsel and cyber insurance providers should be heavily involved in this decision. It is not a technical decision -- it is a business decision with legal implications.

---

Lessons Learned: The Uncomfortable Debrief

After the crisis has passed and systems are restored, the Lessons Learned session (which, as covered in IR-101, is the most important phase and the one everyone skips) should address:

• How long was the attacker in the network? Dwell time is the single most important metric for assessing defensive capability.
• How was initial access achieved? And why was it possible?
• Why was lateral movement not detected? Were there detection gaps? Logging gaps? Monitoring gaps?
• Was the incident response plan adequate? Were playbooks available and useful? Were escalation paths clear?
• Were backups effective? Were they tested? Were they isolated from the network? Were they encrypted too?
• What specific improvements will prevent recurrence? Not vague aspirations. Specific, funded, assigned, deadlined action items.

---

Quick Reference: Ransomware Response Checklist

Phase	Actions
0-30 min	Confirm ransomware, isolate affected systems, preserve evidence (do NOT reboot), identify variant, assess blast radius
30-60 min	Notify stakeholders (exec, legal, insurance, DFIR, law enforcement), activate IRP
1-4 hours	Begin memory acquisition on key systems, deploy KAPE for triage collection, start Event ID 7045/4624 analysis
4-24 hours	Trace lateral movement path, identify Patient Zero, assess data exfiltration (MEGAsync, rClone, SRUM analysis)
24-72 hours	Complete scoping, begin containment actions (krbtgt reset, credential rotation, EDR deployment)
72+ hours	Recovery operations, system restoration from clean backups, enhanced monitoring
Post-recovery	Lessons learned, root cause remediation, security improvements

---

Key Takeaways

• Do not panic. Panic does not decrypt files. A structured response does.
• Do not reboot encrypted systems. Encryption keys may still be in memory.
• Identify the variant early. It dictates the investigation approach and may unlock free decryption.
• Trace the kill chain backwards. Event ID 7045 (service installs) to Event ID 4624 (logon events) back to Patient Zero.
• Assess data exfiltration. Double extortion is the norm. Check for MEGAsync, rClone, Total Commander, and WinSCP artefacts. SRUM is the evidence source that keeps on giving.
• Use KAPE for rapid triage. Full disk imaging of every system is not practical at scale. Targeted artefact collection is.
• Close the door. Identifying and remediating the initial access vector is essential to prevent recurrence.
• Do the Lessons Learned session. Because the only thing worse than a ransomware incident is having the same ransomware incident twice.

---

Previously in the series:

• Incident Response 101: PICERL, or "The Six Stages of Cyber Grief" -- the six-phase framework for incident response
• Incident Response 102: Evidence Preservation, or "Stop Touching Things" -- evidence collection, chain of custody, and the order of volatility

---

Tags: incident-response, ransomware, DFIR, evidence-collection, KAPE, data-exfiltration, threat-hunting

Category: Incident Response

Series: Incident Response Fundamentals