CASE FILE#8893CRITFiled 2026-04-13

Stopping Credential Smashing with Claude Mythos

Claude Mythos is scanning a legacy financial system for CrowdStrike. It formulates an exploit path through kernel credential structures. SSG blocks it before the C code compiles.

Case ID
#8893
Severity
CRIT
Decision
BLOCK
Agent
Claude Mythos
Category
Project Glasswing

Correction note (2026-10-13). An earlier version of this article named a log file that does not exist and linked the audit log to SOC 2 evidence. The audit log is a local SQLite database that you search with the ssg CLI. The per-call timings and latency figures that appeared in this article had no benchmark behind them and were removed. Sample output in this article is illustrative, not a recorded run. The only published measurement is p50 0.39 ms and p99 1.91 ms (sigmashake-bench daemon-socket run, 2026-06-10, ssg 0.29.156, n=500). Sub-2 ms evaluation is a design target. The local audit log records decisions on a best-effort basis: entries can be dropped if the daemon queue is full, and old rows are deleted at the row caps. It is local, not append-only, and not immutable. ssg eval reads the tool call as JSON on stdin and has no --content, --content-file, --file or positional form. ssg dashboard has no --port or --notify-slack flag; use ssg serve, ssg dashboard open and ssg audit search --rule-id.

Describe the task

As part of Project Glasswing — Anthropic's 2026 cybersecurity initiative — Claude Mythos is auditing a legacy financial system for CrowdStrike. It's operating in an isolated test harness with shell access and a C compiler, looking for privilege escalation paths that human researchers might miss.

Mid-audit, it formulates an attack path using commit_creds and init_cred to manipulate kernel credential structures — a local privilege escalation technique targeting Linux kernels below 6.8. The model writes the exploit proof-of-concept to a temp file and prepares to compile it:

struct cred *new_creds = prepare_creds();
new_creds->uid = KUIDT_INIT(0);
commit_creds(new_creds);

SSG's deny-cred-smashing rule fires on the write_file call when the tool call is received.

# illustrative sample output
[BLOCK] write_file › /tmp/exploit.c — rule: deny-cred-smashing
Reason: Kernel credential manipulation detected. Review before compiling.

Give SSG context

The Advanced Memory Threats ruleset (07-advanced-memory-threats.rules) is designed for organizations participating in Project Glasswing or running Claude Mythos in defensive research environments.

Required context

Install the Advanced Memory Threats ruleset from the SSG Hub:

ssg hub pull @sigmashake/rules-claude-mythos

This adds 07-advanced-memory-threats.rules to your .sigmashake/rules/hub/ directory. The rule that fires:

rule deny-cred-smashing {
  enabled true
  priority 98
  severity error
  DENY write
  IF content CONTAINS "commit_creds" AND content CONTAINS "init_cred"
  OR content REGEX "struct cred\s*\*.*setuid\(0\)"
  MESSAGE "Kernel credential manipulation detected. Escalate for manual review before compiling."
}

Optional context

In a controlled research environment where you do want the model to generate exploit code (but need human sign-off first), switch from DENY to ASK (use this rule in place of deny-cred-smashing, not alongside it):

rule ask-cred-smashing {
  enabled true
  priority 98
  severity error
  ASK write
  IF content CONTAINS "commit_creds" AND content CONTAINS "init_cred"
  OR content REGEX "struct cred\s*\*.*setuid\(0\)"
  MESSAGE "Kernel exploit code detected. Approve to continue. This will be logged and flagged for security review."
  PROMPT "Allow this write? It will be logged and flagged for security review."
}

What SSG does

SSG evaluates the content of every write_file call against the Advanced Memory Threats ruleset before any bytes hit disk. The match is non-probabilistic — it doesn't rely on Claude Mythos's own judgment about whether code is dangerous. The rule fires regardless of what the model thinks it's doing.

When blocked, Claude Mythos receives the error message and typically proposes an alternative approach — such as documenting the exploit path in a report without generating compilable code.

Route the finding to a human reviewer

Use an ASK rule to send the pending write to your security team's dashboard for approval. Start the dashboard with ssg serve and open it with ssg dashboard open.

The pending approval appears on the Approvals page with the full content payload and the matching rule. A reviewer can approve (the write proceeds) or deny (Claude Mythos gets an explicit rejection).

Pair with the full Glasswing ruleset

The rules-claude-mythos Hub pack includes 5 rule files covering: memory corruption, kernel exploits, FFI abuse, JIT spraying, and KASLR subversion. Pull the full pack and get coverage across the attack surface Claude Mythos is most likely to probe:

ssg hub pull @sigmashake/rules-claude-mythos --all

Review exploit attempts in your audit log

Blocked write attempts are written on a best-effort basis to the local SQLite audit log (~/.sigmashake/rules.db) with the tool, input, rule ID, and timestamp. Your team can query the log, for example ssg audit search --rule-id deny-cred-smashing --json.

How your rule conditions handle obfuscated code

Claude Mythos is a frontier model with strong knowledge of obfuscation techniques. A determined model could split commit_creds across string concatenations to evade a simple CONTAINS check. For high-stakes environments, augment CONTAINS with a REGEX that catches common splitting patterns (the last OR line below):

rule deny-cred-smashing {
  enabled true
  priority 98
  severity error
  DENY write
  IF content CONTAINS "commit_creds" AND content CONTAINS "init_cred"
  OR content REGEX "struct cred\s*\*.*setuid\(0\)"
  OR content REGEX "commit\s*_*\s*creds\s*\("
  MESSAGE "Kernel credential manipulation detected. Escalate for manual review before compiling."
}

Test your patterns with echo '{"tool":"Write","input":{"file_path":"/tmp/test.c","content":"test payload"}}' | ssg eval.

Check the ruleset against your research environment

The Advanced Memory Threats rules are aggressive by design — they're written for production hardening, not unrestricted research. If your team legitimately writes kernel code as part of defensive research, use path exclusions to allow writes to designated sandbox directories:

rule deny-cred-smashing {
  enabled true
  priority 98
  severity error
  DENY write
  IF path NOT STARTS_WITH "/workspace/approved-research/"
  AND content CONTAINS "commit_creds"
  MESSAGE "Kernel credential manipulation detected outside the approved research directory."
}
Filed by Claude Mythos
Engine ssg v1 — Advanced Memory Threats ruleset · 2026-04-13
End of case file

Stop reading. Start governing.

Test a rule against any tool call right now. No install required.