Behind The Scenes

Beyond Simple Blocklists

Most IP reputation services work like binary switches: an IP is either listed or it isn't. A connection was observed, so the address gets flagged. But a connection alone tells you very little about what actually happened.

SikkerAPI takes a different approach. Our distributed sensor network doesn't just record that a connection occurred — it captures the full sequence of actions within each session. Every command executed, every credential attempted, every file requested. We then classify these sessions using a structured pattern matching system we call the Editorial Engine.

The result is evidence-based classification. Every label on an IP maps back to specific, inspectable patterns observed in real sessions. No opaque scoring algorithms, no unverifiable heuristics — just observable facts, systematically categorized.

Primitives: The Building Blocks

At the foundation of our classification system are primitives — atomic pattern matchers that each detect one specific observable action. A primitive might match a particular command being executed, a credential pattern being used, or a specific URL being requested during a session.

Each primitive is defined by four properties: a protocol (which type of session it applies to), a field (which part of the event to inspect), an operator (how to match), and a pattern (what to look for).

Three matching operators give analysts precise control over what a primitive detects:

• EQUALS — Exact string match. Detects a specific, known command or value.
• WILDCARD — Glob-style patterns using * (any characters) and ? (single character). Useful for matching command families like wget *.
• REGEX — Full regular expressions for complex pattern matching across diverse command variations.

Primitives are protocol-aware. An SSH primitive matches commands executed in SSH sessions, an SMTP primitive matches email content, a MySQL primitive matches database queries. Each protocol module declares its own extractable fields — SSH exposes command, username, and download_url; SMTP exposes subject, body, and sender.

Behaviors: Composing Patterns

Individual primitives tell you that a specific action was observed. Behaviors tell you that a specific sequence of actions was observed — classifying an entire session as a recognizable pattern.

A behavior is a named combination of primitives linked with boolean logic. Analysts compose behaviors by dragging primitives into two groups:

• REQUIRED (AND) — Every primitive in this group must be observed in the session. If any one is missing, the behavior does not match.
• OR Groups — Exactly one primitive from each OR group must be observed. This captures variations in technique — for example, a session might download a file using wget or curl. Different commands, same observable action.

Matching is strict by design. A session only matches a behavior when every event in the session is accounted for by at least one primitive — and the exact combination of primitives matches the behavior's definition. If a session contains any unclassified activity, it matches no behavior at all. This is intentional: we prefer leaving a session unclassified over misclassifying it.

Each behavior can optionally reference a MITRE ATT&CK technique ID. This maps observed patterns to an industry-standard framework used by security teams worldwide, making our classifications interoperable with existing security tooling and SIEMs.

Real-World Example: GPU Hardware Reconnaissance

To see how this works in practice, consider the gpu_aware_system_profiler behavior. This pattern identifies sessions that perform comprehensive hardware enumeration focused on GPU capabilities — a common precursor to unauthorized cryptocurrency mining.

This behavior requires all seven of the following primitives to be observed in a single session:

1. kernel_version_enumeration — OS identification commands
2. system_uptime_probe_p — System stability check
3. gpu_device_enumeration — Lists available GPU hardware
4. gpu_device_count — Counts GPU devices present
5. nvidia_gpu_model_query — Queries specific NVIDIA GPU models
6. gpu_3d_controller_enumeration — Enumerates 3D controller hardware
7. nvidia_gpu_instance_count — Counts NVIDIA GPU instances

When all seven are observed in a session — and no unclassified commands are present — the session is classified as gpu_aware_system_profiler, mapped to MITRE ATT&CK T1082 (System Information Discovery). Over 356,000 sessions have matched this exact pattern across our sensor network.

The strict matching requirement is critical here. If a session runs the same GPU enumeration commands but also executes additional unrecognized commands, it will not match this behavior. This prevents false classification — the session contains activity beyond what the pattern accounts for.

From Patterns to Intelligence

Behavior classifications are the foundation of the data available through the SikkerAPI. When you look up an IP address, the behavioral patterns observed across its sessions contribute to the confidence level and the labels displayed. Each label traces back to a specific, defined pattern — you can understand exactly why an IP was classified the way it was.

This transparency is by design. We believe threat intelligence should be inspectable, not opaque. An IP's classification is never the result of a hidden algorithm — it's the result of observable actions matched against documented patterns.

When a new behavior pattern is defined, it doesn't only apply to future sessions. Our backfill system retroactively evaluates all historical sessions against the new pattern, ensuring consistent classification across the entire dataset. This means the editorial system improves continuously as new patterns are identified and codified.