Ransomware File-Activity Monitoring: Entropy and Attribution

What 1-SEC checks

Ransomware Interceptor correlates supplied file modification activity and entropy-related evidence. Provide accurate file/process attribution and review whether the selected release separates host and process instances; unrelated activity must not be interpreted as one process. Other checks separately inspect known ransomware extensions, canaries, and partial-encryption indicators.

Read the implementation: handleFileActivity

Required telemetry and context

Relevant input events: file_modified, file_change, file_renamed. Use a trusted producer at the real application boundary.

• path
• process_name
• entropy
• host_id
• process_id or pid where available

Field names above describe relevant context, not a complete API request. Consult the current event contract for envelope and detail requirements. Preserve booleans, numbers, and strings as the receiving handler expects them. Agent-provided text cannot independently verify identity or authorization.

Deployment, prevention, and response

Test using temporary synthetic files or the included unit fixtures rather than executing ransomware. Review legitimate backup/encryption workloads and the configured response target. Keep recoverable offline backups and confirm an authorized response actually completes before counting it as containment.

Record the source event, affected agent/host, actual target, policy decision, and response result. Review enforcement configuration separately from detection. A recommendation, selected action, dry-run record, and completed action are different outcomes.

Reproduce the source fixtures

From a checkout of the linked 1-SEC source revision, run the selected fixtures with the repository's Go toolchain. These commands run tests; they do not execute a real attack against your systems.

go test ./internal/modules/ransomware -run '^(TestFileActivityTracker_MassEncryption|TestFileActivityTracker_NoMassEncryption_LowEntropy)$' -count=1

The referenced source fixtures ran in the selected local package suites. Helper tests and synthetic events establish only the assertions shown, not production prevention or framework compatibility.

func TestFileActivityTracker_MassEncryption(t *testing.T) {
	ft := NewFileActivityTracker(5)
	var result ActivityResult
	for i := 0; i < 10; i++ {
		result = ft.RecordModification("evil.exe", "/data/file"+string(rune('a'+i))+".doc", 7.5)
	}
	if !result.MassEncryption {
		t.Error("expected MassEncryption=true for 10 files with high entropy")
	}
}

func TestFileActivityTracker_NoMassEncryption_LowEntropy(t *testing.T) {
	ft := NewFileActivityTracker(5)
	var result ActivityResult
	for i := 0; i < 10; i++ {
		result = ft.RecordModification("notepad.exe", "/data/file"+string(rune('a'+i))+".txt", 3.0)
	}
	if result.MassEncryption {
		t.Error("expected MassEncryption=false for low entropy files")
	}
}

Tuning, evaluation, and coverage limits

High entropy alone is not proof of ransomware: encryption, compression, and backups can be legitimate. A process-level fixture does not demonstrate early prevention on a live filesystem. Missing collector coverage or attribution leaves blind spots.

Evaluate this behavior with representative authorized activity and a controlled known-positive case. Investigate the exact rule, inputs, and state before suppressing an alert. Do not assume a hard-coded heuristic is a configurable setting. Measure your own deployment; the source fixtures do not establish a benchmark, detection rate, compliance certification, or incident-prevention claim.