Threat model
State the asset, trust boundary, attacker capability, and assumptions before testing.
SECURITY RESEARCH / AUTHORIZED LABS
Break assumptions.
Strengthen systems.
This laboratory explores how vulnerabilities emerge, how they can be reproduced safely, and how engineering choices reduce risk. Every interactive tool on this page operates on local, synthetic, user-supplied, or intentionally vulnerable lab data.
Authorization boundary
Use these tools only with systems you own, isolated laboratories, intentionally vulnerable targets, or environments where you have explicit authorization. The browser tools do not scan the public internet, execute remote exploits, collect credentials, establish persistence, or send analysis data off this page.
METHOD
Reproduce locally. Explain the failure. Verify the fix.
Controlled proof
Use deterministic synthetic inputs or intentionally vulnerable demo code rather than uncontrolled targets.
Defensive interpretation
Connect each finding to concrete remediation, detection, regression tests, and residual limitations.
01 / CONTROLLED VULNERABILITY ANALYSIS
Virtual path-boundary analyzer
Compare an intentionally vulnerable path resolver with a bounded resolver in a virtual in-memory filesystem. No real files are read.
Methodology, remediation & limitations
The vulnerable resolver normalizes user input without re-checking that the result remains inside a permitted virtual root. The fixed resolver rejects boundary escapes after normalization. The demonstration models the class of failure; it does not read the host filesystem or issue network requests.
02 / DETERMINISTIC FUZZING
Parser robustness fuzzer
Mutate a small seed corpus against a local URI-decoding record parser, detect exceptions, and minimize the first failing input.
Methodology, remediation & limitations
The target is intentionally tiny and local. The exercise demonstrates seed corpora, mutation, crash detection, deterministic replay, and input minimization. It is not a coverage-guided native-code fuzzer and does not execute external binaries.
03 / LINUX PRIVILEGE REVIEW
Misconfiguration auditor
Analyze a synthetic Linux security snapshot for risky permissions, SUID/capabilities, sudo policy, writable PATH components, and exposed secrets.
Methodology, remediation & limitations
This is configuration analysis, not host enumeration. Findings are mapped to least privilege, ownership/mode correction, sudo scope reduction, capability removal, secret handling, and PATH hardening.
04 / ACTIVE DIRECTORY ATTACK/DEFENSE MODEL
Synthetic privilege-path graph
Trace authorization relationships in a modeled directory graph and explain the defensive control at each edge.
Methodology, remediation & limitations
The graph uses synthetic principals and permissions. It demonstrates relationship reasoning and shortest-path analysis only; it does not query LDAP, authenticate to a domain, request tickets, or perform lateral movement.
05 / CONTAINER HARDENING
Runtime configuration analyzer
Score a supplied container configuration for high-risk privilege, namespace, mount, capability, user, and isolation choices.
Methodology, remediation & limitations
The analyzer evaluates configuration metadata supplied in the page. It does not start containers, mount sockets, invoke a runtime API, or attempt an escape.
06 / ATTACK-SURFACE DISCOVERY
Authorized service inventory analyzer
Turn an imported or user-entered inventory into prioritized exposure findings without performing network discovery.
Methodology, remediation & limitations
The browser version never opens sockets or probes hosts. It analyzes supplied inventory only. A finding is an engineering lead for review, not proof that a service is exploitable.
REPRODUCIBILITY / SOURCE / TESTS
Every result should be explainable.
The tools are deterministic where practical, keep analysis local to the browser, expose the assumptions behind each finding, and separate demonstrated behavior from claims about real systems.
AUTHORED STUDY COMPANION / 3.4
Test a parser and measure a detection rule
Prerequisites. Input contracts, finite numbers, confusion matrices and authorized defensive testing.
A parser must validate semantics as well as delimiters. This local fixture accepts two nonempty comma-separated fields and a finite numeric reading. It rejects missing fields, extra fields, NaN and infinity. Seeded valid cases and explicitly malformed cases exercise the contract without sending traffic to any host.
A separate fictional login dataset labels four events. Alerting at three failures catches one malicious event, misses another and also flags a benign event. The confusion matrix is [[1,1],[1,1]] with true classes as rows and predictions as columns. An alert is a triage signal under the chosen rule, not a confirmed compromise.
Forty generated valid examples plus six malformed examples do not prove the parser secure against every input. Extend the corpus with size limits, Unicode, encodings and resource constraints appropriate to the actual boundary. Preserve failing inputs and an expected outcome. Defensive evidence should distinguish a synthetic fixture, a reproduced bug, and a result observed in an authorized environment.
| Element | Model | Interpretation |
|---|---|---|
| Parser boundary | Syntax + nonempty fields + finite value | Reject before downstream use |
| Detection | Threshold on a fictional event count | Triage signal |
| Evaluation | Labeled confusion matrix | Expose both kinds of error |
Predict, run, compare
Run seed 7 with 40 valid readings. Expect 40 accepted and all six malformed readings rejected. Confirm one false positive and one false negative in the detection fixture.
Download executable notebooks and source Inspect source ↗
Open security.ipynb in the package. Run cells in order, compare with the reference, then change the stated input. Restart the kernel to reset.
Computed reference result — local CPU fixture
{
"valid_accepted": 40,
"invalid_rejected": 6,
"invalid_total": 6,
"detection_confusion": [
[
1,
1
],
[
1,
1
]
],
"scope": "bounded fictional local parser and labeled detection fixtures; no host scanning"
}This is the recorded result of the included code under the package environment. It is not a live service or device measurement.
Extend the experiment
Add a maximum input length and an explicit identifier grammar. Keep the new rejection cases as regression fixtures; explain how alert threshold changes trade false positives against misses.
Check your reasoning: What does a detection alert prove?
- A compromise always occurred — Benign events can match the rule.
- That the event matched the defined rule — Correct. That is the direct supported conclusion.
- That all malicious events were detected — The fixture contains a false negative.
This is an explained self-check, not a certification of mastery.
Claim-specific sources
Reviewed 2026-10-02: this worked example and its explicit assumptions. Source links and notebook results do not establish production or hardware validation.