Add forensic summary command to checkpointctl

[nishantxscooby]

Lately have been exploring checkpointctl and the current parsing capabilities (process tree, file descriptors, sockets via CRIU/crit).

I felt the need for summary command that provides a high-level forensic overview of a checkpoint.

Proposed command:
checkpointctl summary <checkpoint_archive>

My main goal is to build on top of existing parsing logic and provide actual actionable insights rather than raw data.

Initial scope will be:

• total process count
• identification of potentially suspicious processes (e.g. shells, netcat, curl, etc.)
• basic container/network metadata
• detection of sensitive file paths

this would act as a foundation for higher-level forensic analysis and align with Medusa’s direction of enabling attack investigation workflows.

let me know if this aligns with the project goals? :)

[nishantxscooby]

Is this direction acceptable? @rst0git @adrianreber

[adrianreber]

I am skeptical. We have show and inspect already. What is missing from those commands?

[rst0git]

@nishantxscooby I agree with Adrian on this - you can simply copy/paste the output of checkpointctl into ChatGPT, and you will get even better summary :)

[nishantxscooby]

I got your point that a simple “summary” would overlap with existing show and inspect commands. What I was aiming for (but didn’t articulate well) is not just summarization, but adding a forensic analysis layer on top of the existing data.

Specifically, I was thinking of features that identify patterns which are not directly visible from raw output, for example:

• detecting potentially suspicious processes (e.g. shells, netcat usage, reverse shell patterns)
• highlighting access to sensitive paths like /etc/shadow or .ssh
• flagging unusual command patterns from process arguments

So instead of introducing a new command that just reformats output, a better approach might be:

• extending inspect with an optional analysis mode, or
• adding a focused command that performs heuristic-based detection on top of existing parsed data

This would go beyond presentation and actually provide new insights that aren’t currently available.

Does something along these lines is more aligned with what you’d find useful?

[rst0git]

@nishantxscooby One of the challenges with forensic analysis is that checkpoints can be very large - take significant amount of disk space, and parsing their content can take a long time. In our experiments, we use checkpointctl inspect --all --format json (runs only once) to generate a JSON representation of the checkpoints. Then, we analyze this JSON content many times.

The patterns you describe can be defined in a set of instructions that allow AI model to analyse the JSON data and generate a report. For example, you can create such tool using Python (instead of Go) - it will make it easier to implement this functionality.

[nishantxscooby]

Cool that makes sense, and I feel Separating extraction (checkpointctl) from analysis is a much cleaner design.

I’ll explore building a separate analysis tool that consumes the JSON output from checkpointctl inspect --all --format json and performs forensic analysis on top of it.

The idea would be to:

• parse the JSON once
• apply heuristic-based detection (suspicious processes, reverse shell patterns, sensitive file access, etc.)
• generate a structured report

I’ll start with a simple prototype in Python and share progress.

Thankyou :)

[nishantxscooby]

Hi, I've built a small prototype that analyzes the JSON output from:
checkpointctl inspect --all --format=json
It performs simple heuristic-based checks (suspicious processes, sensitive paths, basic network observations) while keeping extraction and analysis separate, here's the link to the repo: https://github.com/nishantxscooby/forensic-checkpointctl
Lmk the feedback on whether this direction makes sense and if the JSON assumptions look correct :)

[nishantxscooby]

@adrianreber @rst0git Please let me know :)