Academic
Mass-encryption detector | Signature-free containment
Stops an unknown program that encrypts files en masse by combining three operating-system signals.
- Development and security analysis
- 2026-07 – 2026-08
Stack
- Python
- Linux
- Terraform
- AWS
Context
The individual final project for IT Security I, the same course as the spyware analysis. The brief asked for a tool that would detect and contain mass encryption on its own, and a test bench to exercise it on.
The scenario is an organisation attacked by a program nobody has seen before. There is no signature to recognise, so containment is decided from what the operating system observes while it happens.
The exercise runs on an ephemeral AWS instance created for it, with no access to any system in use.
Problem
Signature-based antivirus only recognises what it has already seen. A new binary raises no alert, so the encryption advances while somebody identifies it.
Waiting for a person to notice does not work either. By the time someone opens a file and finds it unreadable, the encryption has already reached the rest of the disk.
The project starts from what the operating system observes when a program encrypts files en masse, and from how much of that can be measured without identifying the program.
Technical decisions
The detector uses three independent signals: activity on the filesystem, the entropy of what is written and the volume each process writes. None is conclusive on its own.
A separate component combines them into a score, which is the only thing that orders containment. Since the sensors contain nothing, thresholds are tuned without touching them.
Architecture
A filesystem watcher stores events in a locked buffer. A sampling thread measures every 500 ms how much each process writes and keeps the latest measurement. The main thread reads the score every second and decides whether to act.
A watcher records creations, writes and renames into a locked buffer. It shows that there is activity, but not which process produces it.
The entropy of what is written is measured. Content close to random indicates the file has stopped resembling a document, without opening or identifying it.
Sampling write_bytes per process every 500 ms attributes the volume written to a specific process. It is the only one of the three signals that identifies the responsible party.
No signal contains on its own. Only the component that combines them can order containment.
Containment kills the process tree and moves the binary to a quarantine directory with no execute permission.
The test bench’s infrastructure is described in Terraform. The lab is created and destroyed with one command, and every run starts from the same machine. Terraform state and the variables file stay out of version control, because the state file holds sensitive values in the clear.
Result
The detector contains mass encryption from a binary it has never seen, with nobody intervening, because it reacts to what the process does.
Every threshold adjustment was measured from the same starting machine, so the results can be compared across runs.
What I learned
The threshold was the hard part. A legitimate backup produces a pattern very close to mass encryption: many files written fast, with high-entropy content.
With the three signals available I found no value that separated the two cases. The delivered version prioritises not letting a real case through and accepts false positives. The threshold is documented with that justification.
Here the threshold stopped being a technical decision, because setting it meant choosing which error costs more: stopping a legitimate backup or letting an encryption through.