🛡️ RansomWatch — Starting My Journey Into Ransomware Detection

Ransomware is one of those cybersecurity threats that can turn a normal computer into a disaster in a very short time.

Files start changing rapidly. Processes behave strangely. Important data can become inaccessible.

But what if we could detect these behaviors before the damage becomes too serious?

That's the idea behind my new project: RansomWatch.

🚀 What is RansomWatch?

RansomWatch is a project I'm building to explore AI-based ransomware behavior detection and analysis.

Instead of focusing only on known ransomware signatures, the goal is to monitor system activity and identify suspicious behavioral patterns.

The basic idea is:

System Activity
      ↓
File & Process Monitoring
      ↓
Feature Extraction
      ↓
ML-Based Detection
      ↓
Risk Score
      ↓
Security Alert

The project will also explore using RAG and AI analysis to provide additional context about detected incidents.

🧪 How will I test it?

I'm building a controlled attack simulator that generates ransomware-like behavior for testing.

The purpose isn't to create real ransomware.

Instead, it will provide safe test activity so I can see whether RansomWatch can recognize suspicious behavior and generate an appropriate alert.

🧠 What I want to learn

This project is also a learning journey for me.

While building RansomWatch, I want to understand how different areas of cybersecurity can work together:

• 🖥️ System monitoring
• 📁 File activity analysis
• ⚙️ Process monitoring
• 🤖 Machine learning
• ⚠️ Risk scoring
• 🧾 Digital evidence
• 📚 RAG
• 🧠 AI-assisted analysis
• 🌐 APIs and dashboards

🏗️ Building It From Scratch

I'm not starting with a fully completed system.

I'll be building RansomWatch step by step and documenting the process here on Dev.to.

The first goal is simple:

Build a working detection pipeline before building a fancy interface.

So I'll start with:

Simulator → Monitor → Features → ML → Risk → Alert

Then I'll gradually add the evidence system, RAG, AI analysis, API, and dashboard.

📖 This is just Part 1

This is the beginning of the RansomWatch Build Series.

In the upcoming posts, I'll share what I'm building, the problems I run into, the decisions I make, and what I learn along the way.

I don't expect everything to work perfectly on the first attempt.

That's actually the point.

Build → Break → Understand → Improve.

Let's see where this project goes. 🚀

---

🔗 Project

Project: RansomWatch
Focus: Ransomware Behavior Detection & Analysis
Built with: Python, Machine Learning, System Monitoring, RAG & AI

More updates coming soon.

CyberSecurity #Ransomware #Python #MachineLearning #ArtificialIntelligence #InfoSec #DFIR #ThreatDetection #CyberSecurityProjects #BuildInPublic

follow us for more intresting things to happend

github - NARASIMHAMURTHY4616

linked in - ballanarasimhamurthy

Comments

[Yoshiyuku]

Great starting point — and I like that your first goal is a working detection pipeline before any dashboard. Behavior-based detection is the right direction, since signature matching misses anything new.

A few things I've learned building ML and RAG systems that might save you time later:

1. Beware of a detector that only learns your simulator. If you train and test on the same simulator's output, the model can end up recognizing the simulator's quirks instead of ransomware behavior. Varying the simulator's behavior (speed, file types, ordering, pauses) and holding some variants out for testing will tell you whether it generalizes.

2. Spend as much effort on false positives as on detection. Plenty of legitimate software also writes and rewrites many files quickly, such as backup tools, compression, build systems, sync clients, and photo or video editors. If your benign dataset only contains idle activity, your risk score will look great in testing and be unusable in real life. Collecting benign heavy-write workloads early is worth it.

3. Treat features as the core of the project. Rate-of-change signals (files modified per second, how the rate ramps up), changes in file content randomness, and how activity spreads across directories and across processes are usually more informative than raw counts, and they are also easier to explain in an alert.

For the RAG part later, grounding the explanation on a known knowledge base (for example public technique catalogs and incident response playbooks) will make the alerts more trustworthy than free-form LLM analysis, and it lets you cite where each recommendation comes from.

Looking forward to Part 2 — the Build → Break → Understand → Improve approach is exactly right. Good luck!