Skip to content
ZK
ZAIN KHALIL KHAN
PORTFOLIO
All projects

Interactive build

Ransomware Canary | Behavioural Containment

Behavioural detection model that scores five-second windows of file activity on write volume, write entropy, in-place rename bursts, canary file access, and shadow copy deletion, then triggers containment and reports how many files were lost before it fired.

Live demo readyRansomware + Behavioural Detection
RansomwareBehavioural DetectionEndpoint SecurityIncident ContainmentEntropy AnalysisBlue TeamCase study / interactive demo

Case study

From problem to working system

Problem

Behavioural detection model that scores five-second windows of file activity on write volume, write entropy, in-place rename bursts, canary file access, and shadow copy deletion, then triggers containment and reports how many files were lost before it fired.

My role

Security engineer and full-stack developer

Solution

Behavioural detection model that scores five-second windows of file activity on write volume, write entropy, in-place rename bursts, canary file access, and shadow copy deletion, then triggers containment and reports how many files were lost before it fired.

Architecture

The implementation combines the following technologies and system concerns.

RansomwareBehavioural DetectionEndpoint SecurityIncident ContainmentEntropy AnalysisBlue Team

How it was built

  • Built detection on behaviour rather than signature, since a repacked sample defeats hashing but cannot avoid encrypting files.

Security decisions

  • Built detection on behaviour rather than signature, since a repacked sample defeats hashing but cannot avoid encrypting files.
  • Combined write entropy with in-place rename volume, which is what distinguishes bulk encryption from a compressed nightly backup writing just as fast.
  • Reported time-to-containment and files encrypted before the trigger, which are the only outcome metrics that matter for this control.
  • Made the kill threshold adjustable, exposing the direct tradeoff between files lost and the risk of terminating a legitimate process.

Major challenges

  • Combined write entropy with in-place rename volume, which is what distinguishes bulk encryption from a compressed nightly backup writing just as fast.
  • Treated canary file access and volume shadow copy deletion as high-weight signals because neither has a benign explanation.
  • Included a backup job and ordinary user activity as control scenarios, so the false-positive cost of a naive entropy threshold is visible.

Verified evidence

Results and measurable impact

  • Treated canary file access and volume shadow copy deletion as high-weight signals because neither has a benign explanation.
  • Included a backup job and ordinary user activity as control scenarios, so the false-positive cost of a naive entropy threshold is visible.
  • Reported time-to-containment and files encrypted before the trigger, which are the only outcome metrics that matter for this control.
  • Made the kill threshold adjustable, exposing the direct tradeoff between files lost and the risk of terminating a legitimate process.

No separate numeric outcome is documented, so this section shows shipped technical evidence without inventing metrics.

Screenshots and access

Product view

Open live project

Interactive Demo

A scoped, fully functional recreation of this project's core feature runs below, live in your browser. Reset it, resize it, or expand it to full screen.

Ransomware Canary

Security platform

Ransomware CanaryWorkspace5 updates
Ransomware Canary · Behavioural Detectionpeak behavioural score across the run
contained T+10s

Signature detection loses to a packer, so containment has to come from behaviour. The distinguishing pattern is in-place rename volume at near-maximal write entropy, plus two signals with no benign explanation: a canary file being touched and shadow copies being deleted. Note how the nightly backup writes just as fast.

Bulk encryption in place, then shadow copy deletion.

Signals fired

13

across every window

Time to contain

10s

kill process and isolate host

Files encrypted

304

before containment

Windows analysed

5

5 second buckets

Peak scorekill at 75
100contained
Write entropy per 5s window5 windows · 1,600 writes

Near-maximal entropy alone is not the signal: the backup scenario reaches the same height. Rename volume is what separates them.

Containment fired at T+10s after 304 files were encrypted. Every window after that point never runs.

Window analysis
T+0s12 writes · 0 renames · 4.10 bits0
no action
T+5s48 writes · 6 renames · 6.20 bits0
no action
T+10s310 writes · 298 renames · 7.90 bitsCANARY100
kill process and isolate host

+45 298 in-place renames at 7.90 bits entropy: bulk encryption pattern

+15 310 writes in a 5s window

+30 canary file accessed, no legitimate process reads it

+10 single new extension applied across many files

T+15s640 writes · 631 renames · 7.97 bitsCANARYVSS DELETE100
kill process and isolate host

+45 631 in-place renames at 7.97 bits entropy: bulk encryption pattern

+15 640 writes in a 5s window

+30 canary file accessed, no legitimate process reads it

+35 volume shadow copy deletion attempted

+10 single new extension applied across many files

T+20s590 writes · 584 renames · 7.96 bitsCANARY100
kill process and isolate host

+45 584 in-place renames at 7.96 bits entropy: bulk encryption pattern

+15 590 writes in a 5s window

+30 canary file accessed, no legitimate process reads it

+10 single new extension applied across many files

Zain Khalil Khan