Your computer is doing things right now that you didn’t ask it to do.

Not necessarily malicious things. That’s the annoying part.

Somewhere in the background, a service is checking whether another service is alive. Your desktop environment is talking to a local socket. A browser process you thought you closed is still hanging around. Something is resolving a hostname, something else is maintaining a connection, and systemd has probably started three processes whose names look like rejected pharmaceutical products.

Most of this is normal.

But how would you actually know?

Linux gives us ps, top, ss, lsof, journal logs, /proc, and enough diagnostic utilities to make a small civilization out of troubleshooting. They’re excellent tools. They’re also mostly snapshots, unless you arrange to collect their output continuously.

I wanted something slightly different: a Python program that would quietly record what was happening on my machine, timestamp changes, associate network connections with processes when possible, and leave behind a readable history.

No cloud dashboard. No subscription. No enormous security platform demanding half the machine’s RAM before it will tell me that Firefox connected to the internet.

Just Python, psutil, SQLite, and a little suspicion.

The interesting part turned out to be less about catching anything sinister and more about understanding what suspicious activity actually looks like when it’s surrounded by thousands of completely ordinary events.

The problem with looking only when something seems wrong

Suppose your laptop suddenly gets hot.

You open a terminal.

top

Everything looks normal.

You check network connections:

ss -tunap

Nothing particularly interesting.

You look at running processes:

ps aux  — sort=-%cpu | head

Firefox is eating memory. Shocking development.

The problem is that you’ve started investigating after noticing something unusual.

If a process ran for twelve seconds, opened a connection, transferred data, and exited, it might already be gone.

A snapshot can’t tell you what happened before you took it.

This is why security monitoring systems maintain event histories instead of relying entirely on live dashboards.

I wanted to borrow that idea without dragging in a complete SIEM installation.

The first version would answer four questions:

1. Which processes appeared or disappeared?
2. Which processes opened network connections?
3. Where were those connections going?
4. What changed between observations?

There’s a fifth question, too, although it’s harder:

Should I actually care?

We’ll get to that one.

Start with psutil

Python’s standard library gives us access to plenty of operating-system functionality, but process inspection becomes much easier with psutil.

It’s a cross-platform library for examining running processes, system utilization, network connections, and other operating-system statistics.

On Linux, much of this information ultimately comes from kernel interfaces exposed through /proc.

Install it inside a virtual environment:

mkdir process-watcher
cd process-watcher

python -m venv .venv
source .venv/bin/activate

python -m pip install psutil

Create a file:

nano watcher.py

Before building the actual recorder, it’s worth seeing what the library exposes.

import psutil

for process in psutil.process_iter(
    ["pid", "name", "exe", "username"]
):
    try:
        info = process.info

        print(
            info["pid"],
            info["name"],
            info["exe"],
            info["username"]
        )

    except (
        psutil.NoSuchProcess,
        psutil.AccessDenied
    ):
        continue

This is already more useful than it looks.

Every process has an identifier, but a PID alone isn’t a durable identity. Linux reuses process IDs. Process 4102 today isn’t necessarily the same process 4102 five minutes from now.

For a historical recorder, we need something better.

psutil.Process.create_time() gives us the process creation timestamp.

Combine that with the PID and we have a reasonably reliable identity for an observed process instance.

identity = (
    process.pid,
    process.create_time()
)

This distinction matters because otherwise our event history can quietly become fiction.

Imagine a browser process exits, then an unrelated utility receives the same PID. A naive monitor might decide that the browser transformed into a network utility.

Interesting theory. Terrible telemetry.

Build a process snapshot

The basic monitoring strategy is polling.

Every few seconds, we’ll inspect the system and compare the current state against the previous observation.

This isn’t the same as kernel-level event monitoring. A process can start and finish between polls without ever appearing in our results.

That’s an important limitation, not a minor implementation detail.

For now, though, polling is simple, understandable, and good enough to create a useful diagnostic history.

Here’s a snapshot function:

import psutil

def get_process_snapshot():
    snapshot = {}

    fields = [
        "pid",
        "name",
        "exe",
        "username",
        "create_time",
        "cmdline"
    ]

    for process in psutil.process_iter(
        fields,
        ad_value=None
    ):
        try:
            info = process.info

            pid = info["pid"]
            created = info["create_time"]

            if created is None:
                continue

            identity = (pid, created)

            snapshot[identity] = {
                "pid": pid,
                "created": created,
                "name": info["name"],
                "exe": info["exe"],
                "username": info["username"],
                "cmdline": info["cmdline"]
            }

        except (
            psutil.NoSuchProcess,
            psutil.AccessDenied,
            psutil.ZombieProcess
        ):
            continue

    return snapshot

The result is a dictionary keyed by process identity.

Each entry contains metadata that can help us understand what we’re looking at.

The executable path is particularly useful.

A process called python3 doesn’t tell us very much. A Python interpreter running a script in a temporary directory is a different investigative lead from one running a known application in your home directory.

Neither is automatically malicious.

Context is doing the heavy lifting here.

Detecting new and missing processes

Once we have two snapshots, comparison is straightforward.

previous = get_process_snapshot()

# Later, after the polling interval:

current = get_process_snapshot()

started = current.keys() - previous.keys()
missing = previous.keys() - current.keys()

for identity in started:
    print(
        "STARTED:",
        current[identity]["name"]
    )

for identity in missing:
    print(
        "MISSING:",
        previous[identity]["name"]
    )

Notice the word missing.

A process disappearing from one snapshot doesn’t necessarily prove that it terminated. Permissions, inspection failures, and transient collection problems can affect what the monitor sees.

In a proper event recorder, observations should be distinguished from conclusions.

That’s one of those boring engineering principles that suddenly becomes very interesting when you’re trying to determine whether something actually happened.

Network connections are where things get interesting

Processes are useful, but I was especially interested in outbound connections.

A machine can be doing very little visibly while still communicating with remote systems.

Software updates, browser synchronization, messaging applications, DNS requests, cloud services, and background telemetry can all generate network activity.

psutil.net_connections() exposes socket information, including local addresses, remote addresses, connection status, and process IDs when available.

Try:

import psutil

connections = psutil.net_connections(
    kind="inet"
)

for connection in connections:
    print(
        connection.pid,
        connection.laddr,
        connection.raddr,
        connection.status
    )

On Linux, access to socket information is affected by permissions.

Without sufficient privileges, some connections may be missing from the results, or their owning processes may not be identifiable.

A blank PID does not mean that a connection has no owner.

It means the recorder couldn’t establish one.

That distinction is going to come up repeatedly.

Why socket status matters

TCP connections have states such as:

• ESTABLISHED
• LISTEN
• SYN_SENT
• TIME_WAIT
• CLOSE_WAIT

A listening socket is not the same thing as an outbound connection.

A service listening on 127.0.0.1 may be exposing functionality only to local applications. A service listening on 0.0.0.0 is bound to all IPv4 interfaces, although firewall rules and network configuration still determine whether other machines can reach it.

Likewise, an established connection isn’t inherently suspicious.

A browser maintaining several encrypted connections is expected.

An unfamiliar executable maintaining a connection to an unfamiliar endpoint deserves investigation, but the endpoint alone won’t tell us why the connection exists.

We need to preserve the surrounding information.

Give the recorder a memory

Printing everything to the terminal works until the terminal closes.

I wanted an event history that could survive restarts and be queried afterward.

SQLite is a good fit.

It’s built into Python, doesn’t require a separate database server, and can comfortably handle a modest local event log.

We’ll store:

• The observation timestamp
• The event category
• The process PID
• The process creation time
• The executable name and path
• The remote address
• The remote port
• Additional structured details

I prefer keeping the event payload in JSON while preserving important fields as ordinary database columns.

That makes the history easy to inspect with SQL without forcing every possible event attribute into its own schema column.

The complete recorder

Here’s a functional baseline implementation.

It records process appearances and disappearances, tracks observed network socket changes, and stores everything in SQLite.

It also deliberately avoids logging command-line arguments by default. Those can contain access tokens, passwords, private filenames, and other information you probably don’t want sitting in an unencrypted diagnostic database.

#!/usr/bin/env python3

import argparse
import json
import os
import signal
import sqlite3
import time
from datetime import datetime, timezone
from pathlib import Path

import psutil


DEFAULT_INTERVAL = 2.0

DEFAULT_DB = (
    Path.home()
    / ".local"
    / "share"
    / "process-watcher"
    / "events.db"
)

RUNNING = True


def utc_now():
    return datetime.now(
        timezone.utc
    ).isoformat(timespec="milliseconds")


def stop_handler(signum, frame):
    global RUNNING
    RUNNING = False


def initialize_database(path):
    path = Path(path).expanduser()

    path.parent.mkdir(
        parents=True,
        exist_ok=True,
        mode=0o700
    )

    connection = sqlite3.connect(path)

    connection.execute(
        """
        CREATE TABLE IF NOT EXISTS events (
            id INTEGER PRIMARY KEY AUTOINCREMENT,
            timestamp TEXT NOT NULL,
            event_type TEXT NOT NULL,
            pid INTEGER,
            process_created REAL,
            process_name TEXT,
            executable TEXT,
            remote_address TEXT,
            remote_port INTEGER,
            details TEXT NOT NULL
        )
        """
    )

    connection.execute(
        """
        CREATE INDEX IF NOT EXISTS
        idx_events_timestamp
        ON events(timestamp)
        """
    )

    connection.execute(
        """
        CREATE INDEX IF NOT EXISTS
        idx_events_type
        ON events(event_type)
        """
    )

    connection.commit()

    try:
        os.chmod(path, 0o600)
    except OSError:
        pass

    return connection


def record_event(
    db,
    event_type,
    process=None,
    remote_address=None,
    remote_port=None,
    details=None
):
    process = process or {}

    payload = json.dumps(
        details or {},
        sort_keys=True,
        default=str
    )

    db.execute(
        """
        INSERT INTO events (
            timestamp,
            event_type,
            pid,
            process_created,
            process_name,
            executable,
            remote_address,
            remote_port,
            details
        )
        VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?)
        """,
        (
            utc_now(),
            event_type,
            process.get("pid"),
            process.get("created"),
            process.get("name"),
            process.get("exe"),
            remote_address,
            remote_port,
            payload
        )
    )


def process_snapshot():
    result = {}

    fields = [
        "pid",
        "name",
        "exe",
        "username",
        "create_time"
    ]

    for proc in psutil.process_iter(
        fields,
        ad_value=None
    ):
        try:
            info = proc.info

            pid = info.get("pid")
            created = info.get("create_time")

            if pid is None or created is None:
                continue

            identity = (pid, created)

            result[identity] = {
                "pid": pid,
                "created": created,
                "name": info.get("name"),
                "exe": info.get("exe"),
                "username": info.get("username")
            }

        except (
            psutil.NoSuchProcess,
            psutil.AccessDenied,
            psutil.ZombieProcess
        ):
            continue

    return result


def address_parts(address):
    if not address:
        return None, None

    return address.ip, address.port


def connection_snapshot(processes):
    result = {}

    try:
        connections = psutil.net_connections(
            kind="inet"
        )

    except (psutil.AccessDenied, OSError) as exc:
        raise RuntimeError(
            f"Unable to inspect connections: {exc}"
        ) from exc

    pid_lookup = {
        info["pid"]: info
        for info in processes.values()
    }

    for conn in connections:
        local_ip, local_port = address_parts(
            conn.laddr
        )

        remote_ip, remote_port = address_parts(
            conn.raddr
        )

        process = pid_lookup.get(
            conn.pid,
            {}
        )

        # The socket is unidentified if the
        # owning process could not be resolved.
        created = process.get("created")

        key = (
            conn.pid,
            created,
            conn.type,
            local_ip,
            local_port,
            remote_ip,
            remote_port,
            conn.status
        )

        result[key] = {
            "pid": conn.pid,
            "process": process,
            "local_address": local_ip,
            "local_port": local_port,
            "remote_address": remote_ip,
            "remote_port": remote_port,
            "status": conn.status,
            "socket_type": conn.type
        }

    return result


def describe_event(event_type, info):
    name = info.get("name") or "unknown"
    pid = info.get("pid")

    print(
        f"[{utc_now()}] "
        f"{event_type:<18} "
        f"pid={pid} "
        f"name={name}",
        flush=True
    )


def monitor(db, interval):
    previous_processes = None
    previous_connections = None

    while RUNNING:
        try:
            processes = process_snapshot()
            connections = connection_snapshot(
                processes
            )

        except Exception as exc:
            print(
                f"[{utc_now()}] "
                f"COLLECTION_ERROR: {exc}",
                flush=True
            )

            time.sleep(interval)
            continue

        if previous_processes is not None:
            new_ids = (
                processes.keys()
                - previous_processes.keys()
            )

            missing_ids = (
                previous_processes.keys()
                - processes.keys()
            )

            for identity in new_ids:
                info = processes[identity]

                record_event(
                    db,
                    "PROCESS_OBSERVED",
                    process=info
                )

                describe_event(
                    "PROCESS_OBSERVED",
                    info
                )

            for identity in missing_ids:
                info = previous_processes[identity]

                record_event(
                    db,
                    "PROCESS_MISSING",
                    process=info
                )

                describe_event(
                    "PROCESS_MISSING",
                    info
                )

        if previous_connections is not None:
            new_connections = (
                connections.keys()
                - previous_connections.keys()
            )

            missing_connections = (
                previous_connections.keys()
                - connections.keys()
            )

            for key in new_connections:
                info = connections[key]

                record_event(
                    db,
                    "SOCKET_OBSERVED",
                    process=info["process"],
                    remote_address=info[
                        "remote_address"
                    ],
                    remote_port=info[
                        "remote_port"
                    ],
                    details={
                        "local_address": info[
                            "local_address"
                        ],
                        "local_port": info[
                            "local_port"
                        ],
                        "status": info["status"],
                        "socket_type": info[
                            "socket_type"
                        ]
                    }
                )

            for key in missing_connections:
                info = previous_connections[key]

                record_event(
                    db,
                    "SOCKET_MISSING",
                    process=info["process"],
                    remote_address=info[
                        "remote_address"
                    ],
                    remote_port=info[
                        "remote_port"
                    ],
                    details={
                        "local_address": info[
                            "local_address"
                        ],
                        "local_port": info[
                            "local_port"
                        ],
                        "status": info["status"]
                    }
                )

        previous_processes = processes
        previous_connections = connections

        db.commit()

        time.sleep(interval)


def main():
    parser = argparse.ArgumentParser(
        description=(
            "Local process and network "
            "activity recorder"
        )
    )

    parser.add_argument(
        "--interval",
        type=float,
        default=DEFAULT_INTERVAL
    )

    parser.add_argument(
        "--database",
        default=str(DEFAULT_DB)
    )

    args = parser.parse_args()

    if args.interval <= 0:
        parser.error(
            "--interval must be positive"
        )

    signal.signal(
        signal.SIGINT,
        stop_handler
    )

    signal.signal(
        signal.SIGTERM,
        stop_handler
    )

    db = initialize_database(
        args.database
    )

    print(
        f"Recording to {args.database}"
    )

    print(
        f"Polling every {args.interval}s"
    )

    print(
        "Press Ctrl+C to stop."
    )

    try:
        monitor(
            db,
            args.interval
        )

    finally:
        db.commit()
        db.close()


if __name__ == "__main__":
    main()

There are a few deliberate design choices here.

The initial snapshot establishes a baseline rather than recording every existing process as newly started.

The database stores observation timestamps in UTC. This makes records easier to correlate with other logs across time zones.

Socket identity includes the local endpoint, remote endpoint, protocol type, process identity where available, and connection status. A change in TCP state can therefore produce a missing-socket event followed by an observed-socket event.

That doesn’t mean a new physical connection was necessarily created.

Also, psutil does not expose a stable socket identifier through this API. A reused endpoint tuple can represent a different socket. UDP observations are even less expressive because they don’t have TCP-style connection states.

This is a polling-based activity recorder, not a perfect socket lifecycle tracer.

And while the database permissions reduce accidental exposure, they don’t protect against another process running with the same user privileges. The monitor is intended for a trusted personal machine, not as a tamper-resistant forensic appliance.

Running the monitor

Start it with:

python watcher.py

Or change the polling interval:

python watcher.py --interval 1

A shorter interval increases the chance of observing short-lived activity, but it also increases collection overhead.

Scanning system-wide network connections can be relatively expensive, particularly on machines with large numbers of sockets.

I wouldn’t default to polling ten times per second just because the option exists.

For ordinary desktop diagnostics, one or two seconds is a reasonable starting point. Measure the overhead on your own system before deciding what interval makes sense.

On Linux, you can check the monitor itself with:

ps -o pid,%cpu,%mem,etime,cmd -C python

If you need visibility into sockets belonging to other users, additional privileges may be required. Run the tool unprivileged first and understand the gaps before considering elevated execution.

Query the history

The recorder writes events into:

~/.local/share/process-watcher/events.db

If the SQLite command-line client is installed, inspect the database:

sqlite3 ~/.local/share/process-watcher/events.db

List the most recent events:

SELECT
    timestamp,
    event_type,
    pid,
    process_name
FROM events
ORDER BY id DESC
LIMIT 30;

Find remote endpoints:

SELECT
    timestamp,
    process_name,
    remote_address,
    remote_port
FROM events
WHERE event_type = 'SOCKET_OBSERVED'
  AND remote_address IS NOT NULL
ORDER BY id DESC
LIMIT 50;

Find the most frequently observed remote endpoints:

SELECT
    remote_address,
    remote_port,
    COUNT(*) AS observations
FROM events
WHERE event_type = 'SOCKET_OBSERVED'
  AND remote_address IS NOT NULL
GROUP BY
    remote_address,
    remote_port
ORDER BY observations DESC
LIMIT 20;

That last query is useful, but be careful interpreting it.

The count represents observed socket-state appearances, not connection attempts, packets, bytes transferred, or unique communications.

A noisy process can generate many records without doing anything dangerous.

A malicious process might generate one record, or none if it runs entirely between polling intervals.

Numbers are very good at looking authoritative while quietly measuring something other than what you think they’re measuring.

So what does suspicious activity actually look like?

This is where the project stops being a straightforward Python exercise.

A process connecting to an unfamiliar IP address is not automatically suspicious.

Neither is an executable running from a temporary directory.

Neither is a background process starting without a visible application window.

Linux desktops contain plenty of software that behaves in ways that look strange until you understand its purpose.

Package managers create temporary files. Browsers launch sandboxed helper processes. Desktop services communicate over local sockets. Updaters contact remote servers. Applications use content delivery networks whose IP addresses change.

Even ordinary Python tooling can look questionable.

A development server might listen on a network interface. A test suite might create dozens of short-lived processes. A package installation might contact several different domains.

You could build an alert system that treats all of these behaviors as suspicious.

It would be spectacularly annoying.

The better approach: investigate combinations

Consider a hypothetical sequence:

A new executable appears in an unexpected directory.

The executable has no obvious relationship to the application you were using.

It starts repeatedly.

Each time it runs, it establishes an outbound connection to the same remote endpoint.

Its parent process is unexpected.

That combination is more interesting than any individual event.

But our current recorder doesn’t capture parent-process relationships or executable hashes. It also doesn’t prove that a particular process initiated a connection, only that the socket was associated with it during an observation.

So we’d need to collect more evidence before making a claim.

This is why I dislike security dashboards that reduce everything to a red warning icon and a vaguely threatening number.

The important part is the evidence behind the warning.

Add executable hashing

One useful extension is recording the SHA-256 hash of executable files.

That gives us a way to distinguish binaries even when their filenames are identical.

import hashlib
from pathlib import Path


def sha256_file(path):
    digest = hashlib.sha256()

    try:
        with Path(path).open("rb") as file:
            while True:
                chunk = file.read(
                    1024 * 1024
                )

                if not chunk:
                    break

                digest.update(chunk)

    except (OSError, TypeError):
        return None

    return digest.hexdigest()

You could call this when a previously unseen executable path appears, rather than repeatedly hashing every running process.

Hashing has costs, and the file on disk might have changed since the process started. A hash of the current path isn’t necessarily a hash of the exact executable image currently mapped into memory.

Still, it’s useful metadata.

It can help answer whether two suspicious-looking events involved the same binary, or whether an executable at a familiar path has changed.

For a more complete implementation, I’d also record parent PID, parent creation time, file ownership, and the result of any executable-path inspection.

The thing this tool cannot see

There’s a major blind spot in our design.

Polling isn’t event tracing.

A process can start, make a connection, and disappear between two snapshots.

Likewise, a TCP connection can be established and closed before the next poll.

You can shorten the interval, but you cannot eliminate this limitation through polling alone.

On Linux, more complete approaches include kernel audit facilities, eBPF instrumentation, and other event-based tracing mechanisms.

For example, eBPF programs can attach to selected kernel tracepoints or hooks and report events as they occur.

That opens the door to a more capable recorder, although it introduces kernel-version differences, privilege requirements, event-buffer management, and considerably more complicated code.

There’s also a distinction between observing a network connection and observing what data was transmitted.

Our Python recorder captures socket metadata.

It does not capture packet payloads.

It cannot tell whether a connection transmitted a password, downloaded a software update, or exchanged a few harmless bytes.

A destination address and port are not a transcript.

That’s a fairly important distinction if you’re going to use this kind of information for security investigations.

Turning observations into useful alerts

The next logical step is a rules engine.

But I wouldn’t begin with an enormous collection of supposedly suspicious indicators downloaded from somewhere.

I’d start with local baselines.

Record activity for a while. Identify familiar applications, recurring services, expected endpoints, and normal startup patterns.

Then look for changes.

Examples of useful investigative rules might include:

New executable in an unusual location: A previously unseen binary appears under a temporary or user-writable directory and starts making network connections.

Unexpected listener: A process begins listening on a non-loopback address where no corresponding service was previously observed.

Repeated unfamiliar destination: The same process repeatedly appears with connections to an endpoint that hasn’t been part of the machine’s normal activity.

Changed executable: A familiar executable path now has a different file hash, without an obvious software update.

These should produce investigation candidates, not automatic declarations of compromise.

The difference matters.

If a monitoring tool confidently tells you that ordinary behavior is malicious, eventually you’ll either stop trusting it or start breaking things to satisfy it.

Neither outcome is particularly useful.

A privacy tool that creates its own privacy problem

There’s a slightly uncomfortable detail here.

We’re collecting a history of application behavior.

That history can reveal quite a lot about the person using the computer.

Even without packet contents, network metadata can expose patterns involving work schedules, software usage, communications, and browsing activity.

Executable paths may contain usernames or project names.

Command-line arguments can contain secrets.

A local monitoring database is itself sensitive information.

So if I were extending this into a tool intended for long-term use, I’d add a retention policy, database size limits, configurable exclusions, and a clear option to disable collection of particular fields.

For example, SQLite makes it easy to delete old events:

DELETE FROM events
WHERE timestamp < datetime(
    'now',
    '-7 days'
);

However, our timestamps use ISO 8601 formatting with a T separator, while SQLite’s default datetime() output uses a space.

For reliable comparisons, use a cutoff generated in Python with the same timestamp format as the stored records:

from datetime import (
    datetime,
    timedelta,
    timezone
)

cutoff = (
    datetime.now(timezone.utc)
    - timedelta(days=7)
).isoformat(timespec="milliseconds")

db.execute(
    "DELETE FROM events WHERE timestamp < ?",
    (cutoff,)
)

db.commit()

Deletion also doesn’t guarantee immediate removal of historical bytes from the database file or associated storage.

SQLite may retain freed pages for reuse, and filesystem backups or snapshots may preserve older copies.

For a privacy-conscious deployment, retention should be designed from the beginning rather than bolted on after the database has accumulated months of activity.

A tool that watches everything can become a very convenient archive for someone else.

Wonderful. We invented another problem.

What I’d build next

The baseline recorder is intentionally small enough to understand.

It can tell us what processes and sockets were visible at each polling interval and preserve changes for later inspection.

That’s useful, but there’s room to make it considerably better.

I’d extend it with a few specific capabilities.

First, a proper process ancestry model. Knowing that a process exists is less useful than knowing which process launched it, when, and under what executable identity.

Second, DNS correlation. An IP address is often a poor investigative clue by itself. Capturing relevant DNS observations would help connect some network activity to hostnames, while recognizing that DNS caching, encrypted DNS, shared addresses, and application-level resolution complicate attribution.

Third, an event-based backend for Linux. The polling implementation could remain available as a portable fallback, while a kernel-supported event source captures short-lived process and network activity more reliably.

Fourth, a local HTML report generator.

Not another dashboard running seventeen JavaScript frameworks.

An actual report: timestamped events, executable identities, remote endpoints, and a timeline that can be opened in a browser without requiring an account.

I’d also want a baseline comparison mode so I could record an ordinary desktop session, install a new application, record another session, and examine the differences.

That would be useful for privacy investigations, software testing, and understanding unfamiliar applications.

It would also be a considerably more honest experiment than installing a random network monitor and declaring every unfamiliar connection evidence of espionage.

The strange comfort of knowing what’s running

The thing I like about this project is that it replaces vague suspicion with observable data.

Computers are noisy.

Modern desktop software is complicated. Applications launch helper processes, maintain background connections, schedule work, and communicate with services you might not recognize.

Most of that behavior is entirely legitimate.

Some of it is unnecessary.

Occasionally, something genuinely deserves closer attention.

The difficult part isn’t collecting a list of processes or remote addresses. Python makes that relatively easy.

The difficult part is preserving enough context to understand what the observations mean.

That’s where a simple recorder becomes an actual engineering project.

And there’s something satisfying about building your own instruments instead of trusting a dashboard whose detection logic you can’t inspect.

The code isn’t magic. It doesn’t identify malware, inspect encrypted traffic, or guarantee complete visibility into the operating system.

It watches what it can see, records changes, and gives you something concrete to investigate.

For a few hundred lines of Python and a SQLite database, that’s a decent start.

⸻

If you want to take this approach further, my Python Automation Ninja toolkit focuses on building practical Python utilities, automation workflows, and reusable tooling. The point is to own the machinery, understand how it works, and stop treating every useful system capability as something that requires another subscription.

• Python Automation Ninja: 10 Custom Python Automations
• SHELL SHOCKED: The Underground Megapack of Python and Bash Scripts - 8 Guides, No GUI, All Power

The monitoring code in this article is a standalone starting point. You can modify it, extend the event model, or replace the polling backend entirely.

Your computer has been doing things without asking you for years. You might as well start keeping receipts.

I Built a Python Tool That Watches What My Computer Does Behind My Back was originally published in Code is Data, Data is Code on Medium, where people are continuing the conversation by highlighting and responding to this story.