What It Catches

Observer's detections fall into three categories by how they're classified. Policy engine events are identity-based and deterministic. Seed patterns are content-based and deterministic. Everything else is routed through the LLM and cached for future deterministic lookup.

Policy Engine

Host identity events from journald. These never reach the LLM — the rules are unambiguous.

SSH logins

• Unknown IP logs in → immediate email with source IP, username, timestamp
• Trusted IP logs in → silent
• Failed authentication → suppressed as part of general SSH brute force filtering (unless part of a larger pattern)

SSH brute force attempts are recognized structurally and suppressed. Every public-facing SSH server sees thousands per day; alerting on them is noise. Observer only cares about successful logins from IPs you haven't explicitly trusted.

User and privilege changes

• useradd → escalation. An attacker's first persistence move after gaining a shell is usually creating a new user.
• usermod -aG sudo, usermod -aG wheel → escalation.
• passwd on a user account → alert.
• Failed sudo attempt → alert (real users occasionally mistype; repeated failures escalate).

SSH key tampering

Any write to ~/.ssh/authorized_keys — for any user — is an escalation event. Adding an SSH key is how attackers maintain access after an initial exploit is patched. There's no legitimate reason for this file to change outside a deliberate admin action.

Seed Patterns

Content signatures that, if they appear in any log stream on any server, always mean exploitation has occurred. Observer ships with these seeded at startup.

Credential dumps

• root:x:0:0:root — /etc/passwd contents appearing anywhere in log output means the attacker has read the file and something is echoing it back. The path /etc/passwd in a URL is recon; the contents in output is confirmed compromise.
• /etc/shadow hash patterns — hashed passwords in output.
• AWS credential patterns — AKIA... / aws_secret_access_key= in output.

Private keys in output

• -----BEGIN RSA PRIVATE KEY-----
• -----BEGIN OPENSSH PRIVATE KEY-----
• -----BEGIN EC PRIVATE KEY-----
• -----BEGIN DSA PRIVATE KEY-----
• -----BEGIN PRIVATE KEY-----

No legitimate application prints private keys to stderr or stdout. If one shows up in log output, key material is being exfiltrated.

Reverse shells and remote execution

• bash -i >& /dev/tcp/... — classic reverse shell
• nc -e /bin/sh, nc -e /bin/bash — netcat reverse shell
• curl ... | sh, wget ... | sh — remote script download and execute
• base64 -d | bash, base64 -d | sh — base64-encoded payload execution
• python -c "import socket..." — Python reverse shell primitive

Destructive commands

• rm -rf /, rm -rf /*, rm -rf /tmp/* in a path that looks exploitative
• Filesystem overwrites with known destructive patterns

LLM Classification

Everything that isn't obviously determined by the Policy Engine or a seed pattern goes to the LLM. The LLM is asked to classify with intent-and-outcome awareness — not just "is this an attack?" but "is this attack working?"

Injection attacks

• SQL injection — UNION SELECT, OR 1=1, stacked queries, comment-based injections, blind SQLi patterns
• Shell injection — command separators, pipe chains, backtick substitution, encoded command sequences
• Command chaining — ;, &&, ||, | in request parameters
• PHP wrappers — php://filter, php://input, data://, expect://
• Encoded payloads — URL-encoded, double-encoded, base64, unicode escaping
• Path traversal — ../, ..\\, encoded variants targeting /etc/passwd, .env, config backups

Evidence capture distinguishes recon from exploitation: a SQL injection payload that got a 404 is recon; the same payload getting a 200 with database contents is exploitation.

Vulnerability scanners

• Nuclei, CensysInspect, ZMap — recognizable by their request patterns and User-Agents
• ProxyShell / ProxyNotShell — Exchange Server CVE probes
• Log4Shell — JNDI injection patterns
• Spring4Shell — ClassLoader manipulation attempts

Scanner probes are almost always dropped after the LLM sees the server returned a 404 or default page. When one of them actually works — the server returns sensitive data or execution output — the verdict flips and an email fires.

Novel and zero-day patterns

The LLM classifies patterns it has never seen before. AI-generated payloads, encoded evasions, exploits for CVEs that didn't exist when Observer was deployed. The first time such a pattern arrives, the LLM takes seconds. Every repeat after that is a cache hit.

Observer has been validated end-to-end against CVE-2025-55182 (React2Shell) — a CVSS 10.0 pre-auth RCE in Next.js 15.0.0. The attack was classified as malicious deterministically (via seed pattern matching /etc/passwd contents in container output), escalated through the non-HTTP direct-dispatch path, and emailed in under a second.

Data exfiltration

Observer catches data exfiltration attempts by looking at what the server returns, not just what the attacker requested. Large responses, unusual content-types, known-sensitive path patterns all factor in. Evidence capture grounds the verdict in what actually left the server.

What Observer does not catch

Honesty about the product's boundaries:

• Network-level exfiltration — Observer watches logs, not packets on the wire. For DNS tunneling, UDP covert channels, or bulk data egress over allowed ports, see VaultDEC-1.
• Memory-only attacks — process injection, kernel exploits that don't touch disk or logs. Observer is a log security tool; these are out of scope.
• Log-avoiding attackers — an attacker who knows Observer is running and takes care not to generate log output won't be caught by log analysis. This is why Observer is one layer in a defense-in-depth strategy.
• Windows servers — Linux-only. No Windows support planned.

The design philosophy is narrow and deep: do log security really well, with evidence, at low cost, with a clean deployment model. For everything outside that scope, pair Observer with the right tool — DEC-1 for egress, kernel-level EDR for memory-resident threats, etc.