← Back to list

I Built a Forensic Snapshot Daemon in Python — And GitHub’s Copilot Found Bugs in It

Building SecSnap: a real-time system monitor for SOC and DFIR workflows, and what I learned when automated security review flagged my own…

Abiram R · 2026-06-10 04:25 · 4 claps · 5.2 min read
#dfir #cybersecurity #open-source #python #digital-forensics
Open on Medium ↗
Wiki topics: LLM · Large Language Models 🔒 · Cybersecurity 🔓 · Open Source

I Built a Forensic Snapshot Daemon in Python — And GitHub’s Copilot Found Bugs in It

Building SecSnap: a real-time system monitor for SOC and DFIR workflows, and what I learned when automated security review flagged my own tool.

Why I Built This

When I started learning cybersecurity seriously, something grabbed my attention. Most beginner projects are either too simple to be meaningful or too complex to finish. Log parsers, port scanners, basic vulnerability scanners are all useful for learning, but not the kind of thing that demonstrates real understanding of how security operations actually work.

I wanted to build something that solved a real problem. Something a SOC analyst or DFIR investigator would actually find useful in their day-to-day work.

The problem I kept coming back to was this: when a security incident happens, the first challenge is preserving evidence. Systems get rebooted, logs get overwritten and processes disappear. By the time an analyst sits down to investigate, half of the forensic data is already gone.

SecSnap was my answer to that problem. A Python daemon that runs quietly in the background, monitoring system activity continuously, and automatically captures a complete forensic snapshot the moment something suspicious happens. No manual intervention required.

What SecSnap Does

SecSnap is a background daemon — a process that runs continuously without user interaction, monitoring four key areas of the system.

CPU activity is tracked per core, including usage percentage, frequency, and load averages. Spikes above a configurable threshold trigger a snapshot automatically.

RAM consumption is monitored including total, used, and free memory alongside a live list of the top memory-consuming processes. If a process suddenly consumes an abnormal amount of memory, that’s a signal worth capturing.

Network connections are monitored for active sessions and outbound connections to known malicious ports. The tool ships with a default list of suspicious ports including 4444 (Metasploit), 1337, 31337, 9001, and 6667 — common backdoor and C2 ports.

Disk activity tracks I/O rates, mounted partitions, and recently modified files in the /tmp directory. Abnormal write rates can indicate data exfiltration, ransomware activity, or malware dropping payloads.

Daemon running, system nominal SecSnap daemon running in the background, continuously monitoring system activity

Daemon running, system nominal SecSnap daemon running in the background, continuously monitoring system activity

When any of these triggers fires, SecSnap immediately captures a complete system snapshot and saves it as both a human-readable TXT report and a structured JSON file, timestamped and preserved in a snapshots directory.

The Architecture

The project is built with modularity in mind. Each data source has its own collector module, the daemon handles monitoring logic, and the reporter handles output. This separation makes the code easier to maintain, test, and extend.

secsnap/
├── daemon.py
├── snapshot.py
├── reporter.py
├── notifier.py
├── config.py
└── collectors/
    ├── cpu.py
    ├── memory.py
    ├── network.py
    └── disk.py

Project structure (ls -la output) SecSnap’s modular project structure — each collector is isolated in its own module

Project structure (ls -la output) SecSnap’s modular project structure — each collector is isolated in its own module

The daemon runs a check every 10 seconds by default. If a trigger fires and the cooldown period has passed, it calls the snapshot assembler which pulls data from all four collectors simultaneously, then passes the result to the reporter.

A cooldown mechanism prevents snapshot flooding. If something triggers repeatedly in quick succession, SecSnap waits a configurable number of seconds before capturing another snapshot. This prevents a noisy system from filling up disk space with redundant captures.

What a Snapshot Looks Like

Here is an example of a triggered snapshot report:

Triggered snapshot output SecSnap detecting a CPU spike and automatically capturing a forensic snapshot

Triggered snapshot output SecSnap detecting a CPU spike and automatically capturing a forensic snapshot

Every snapshot is timestamped, self-contained, and preserves the full system state at the moment of the trigger. The JSON version of the same data can be fed directly into a SIEM or parsed by downstream tooling.

Snapshot TXT report A complete forensic snapshot — CPU, memory, network, and disk state preserved at the moment of the trigger

Snapshot TXT report A complete forensic snapshot — CPU, memory, network, and disk state preserved at the moment of the trigger

Adding Security Features

As the project grew I added several features that made it more production-ready.

A configurable whitelist system lets you define trusted IPs and processes that should never trigger alerts. Without this, system processes like Xorg and kworker would constantly fire false positives.

Email alerting was added using Python’s smtplib, sending immediate notifications to a configured recipient when a snapshot is triggered. This is disabled by default and configured through environment variables.

Configurable thresholds mean the tool adapts to different environments. A busy development machine needs different trigger points than a production server.

When GitHub’s Copilot Found Bugs in My Security Tool

After pushing the initial version to GitHub, I had Copilot audit the repository for potential risks and it identified a few issues. This was uncomfortable and useful in equal measure.

The first issue was hardcoded email credentials in config.py. I had placeholder values like “your@gmail.com” which GitHub flagged as potential credential exposure. The fix was moving all sensitive values to environment variables using os.environ.get().

The second issue was broad exception handling in collectors/disk.py. I had written bare except Exception: pass blocks that silently swallowed all errors. This is dangerous in a security tool because it hides real problems. The fix was replacing them with specific exception types such as OSError, PermissionError and logging errors at appropriate levels instead of discarding them.

The third issue was a directory traversal risk in the /tmp scanner. The os.walk call followed symlinks without boundary checks, meaning a malicious symlink in /tmp could cause the scanner to read files outside the intended directory. The fix was adding followlinks=False, using os.path.realpath() to resolve true paths, and validating that every resolved path still starts with /tmp before processing it.

The fourth issue was SMTP authentication using a plain account password. The fix was adding explicit SSL context via ssl.create_default_context() and documenting the use of Gmail App Passwords with guidance on OAuth2 for production deployments.

Finding vulnerabilities in a tool I built specifically for security work was a good reminder that secure coding requires active attention, not just good intentions.

GitHub security advisories GitHub’s Copilot flagging vulnerabilities in the tool itself

GitHub security advisories GitHub’s Copilot flagging vulnerabilities in the tool itself

What This Taught Me

Building SecSnap gave me a much clearer understanding of what forensic readiness actually means in practice. The value of a forensic snapshot isn’t just the data it contains but also it’s the timing. Evidence captured automatically at the moment of an anomaly is significantly more valuable than evidence collected after the fact.

The GitHub security findings reinforced something I already knew intellectually but now understand practically; every piece of code is a potential attack surface. A security tool with vulnerabilities is worse than no tool at all because it creates false confidence.

The exception handling fix in particular changed how I write Python. Broad exception handling is a habit that develops naturally because it makes code easier to write. Breaking that habit requires deliberate effort.

Ever since I realized that there are bound to be issues with what you build. i started auditing the codebase regularly for potential issues, marking them down in Github issues and then working towards securing them.

What’s Next

Several features are planned for future releases along with a lot of fixes to implement. Process tree capture will record parent and child process relationships at the time of each snapshot, providing deeper context for investigating suspicious activity. SIEM export via syslog will allow snapshots to be forwarded to centralized logging infrastructure. A systemd service file will enable proper daemon deployment on Linux systems.

The project is open source and actively maintained.

GitHub: github.com/abiramr44/secsnap


메타데이터
post_id
6fcdb46fe096
slug
i-built-a-forensic-snapshot-daemon-in-python-and-githubs-copilot-found-bugs-in-it-6fcdb46fe096
url
https://medium.com/@abiramr44/i-built-a-forensic-snapshot-daemon-in-python-and-githubs-copilot-found-bugs-in-it-6fcdb46fe096
canonical_url
https://medium.com/@abiramr44/i-built-a-forensic-snapshot-daemon-in-python-and-githubs-copilot-found-bugs-in-it-6fcdb46fe096
author_url
https://medium.com/@abiramr44
status
ok
fetched_at
2026-06-15 20:49:13