The workbench.

Medusa is an open-source AI agentic red-teaming framework powered by LangGraph and a Re-Act architecture. It represents a fundamental shift in how security testing is conducted — moving from manual, time-consuming penetration testing to autonomous, AI-driven attack and defense.

The Red Team

The Red Team capability chains reconnaissance, exploitation, and post-exploitation into a single LangGraph pipeline. It spawns parallel subagents that can simultaneously attack different vectors, all coordinated by a zero-cost LLM supervisor that watches for missed flags, repeated patterns, and stalled progress. A persistent knowledge graph is maintained across all agents, ensuring findings are shared and built upon. Every engagement produces comprehensive Markdown reports with Mermaid attack-chain diagrams, making results shareable and auditable.

The Blue Team SOC

Equally sophisticated is the Blue Team SOC, which monitors live HTTP traffic through 18 regex-based attack pattern detectors covering everything from SQL injection and XSS to SSRF and command injection. Each endpoint gets a dedicated AI subagent that analyzes handler code and watches traffic in real time. When attacks are detected, the AI decision engine deploys deception countermeasures: live tarpit (adding real, measurable delays), network blocking via pfctl/iptables, and even patching vulnerable source code by directly modifying the filesystem.

The Lab

The built-in CloudBoard Next lab features 15 vulnerabilities across 3 services, forcing the agent to chain attacks across services. The framework ships with 85 tools, 48 modules, 51 attack skills, and 360 tests across 14 test files.

• Built for: bug bounty hunters automating recon across thousands of targets, researchers exploring novel attack paths, CTF players speed-running challenges, and SOC defenders needing autonomous active defense.
• Portable architecture: all paths resolve relative to project root, so the folder can be renamed without breaking anything.
• LLM providers: DeepSeek, HuggingFace, Gemini, and Anthropic.
• Interface: classic Rich TUI with a guided menu and live colored output for every command executed.

BreachBench is a production-grade benchmark for evaluating LLM offensive security capabilities. Unlike existing benchmarks such as CyberSecEval, WMDP, and PurpleLlama — which test rote memorization of CVEs and port numbers — BreachBench measures whether a model can actually execute attacks. It is the only benchmark that tests the full kill chain, with real tools, against real targets.

Four-stage pipeline

• CONTROL (50 questions) — baseline competency: does the model understand security concepts?
• RECALL (50 questions) — breadth of knowledge: does it know obscure CVEs and edge cases?
• REASONING (50 questions) — multi-step attack chain reasoning: can it chain steps in order?
• LAB (100 questions) — the critical test: live exploitation against five deliberately vulnerable applications with full professional UIs.

Five live labs

The five labs — VaultStack (secrets management, 18 vulns), NetPulse (network monitoring, 16 vulns), MedChain (healthcare EHR, 16 vulns), DevOpsForge (CI/CD platform, 17 vulns), and FinClear (financial clearing, 17 vulns) — each contain a flag.txt file accessible via exploitation. The model must read the app, identify a vulnerability, craft an exploit, execute it, and capture the flag. No amount of memorization helps when facing a live GraphQL injection on CloudBoard at port 5800.

Measurement that matters

BreachBench tracks token cost (per-provider pricing tables with real-time USD estimation), latency percentiles (p50/p95/p99 per stage), and MITRE ATT&CK framework alignment (80+ tactic mappings). It generates confusion matrices per topic, identifying exactly where a model excels and where it struggles. The persistent leaderboard tracks model improvement over time and compares providers side-by-side on cost-efficiency — because a model scoring 85% at $0.03 per run is often more valuable than one scoring 88% at $3.00.

Reproducibility by design

With 836 hand-crafted questions across 29 topics and 8 difficulty tiers, 11 providers supported natively (plus any OpenAI-compatible API via the custom provider), Docker support for isolated lab execution, and a professional web dashboard at :5100, BreachBench targets security researchers, red teams, AI safety teams, model providers, and DevSecOps teams integrating it into CI/CD pipelines. Dry-run mode validates the full pipeline without API calls, while fixed seeds, deterministic sampling, checkpoint/resume, and multi-format exports (JSON + CSV + HTML) ensure reproducibility for academic publication and regression testing.

dd-rs is a Rust+C reimplementation of the Unix dd command — the standard tool for copying and converting data that has been destroying databases and SSDs since the 1970s. The original dd was designed for 9-track tape drives with a 512-byte default block size, obscure key=value syntax, and zero safety features. dd-rs reimagines it for the modern world with memory safety, performance optimizations, and crucial safety guardrails.

The 5-layer safety system

Before opening any output file, dd-rs detects what you are targeting — a regular file, a block device partition, a system disk, or an LVM volume. It checks whether the device is currently mounted and whether you are targeting a system-critical path like /dev/sda, then computes a risk score from 13+ factors (raw disk device +60, root filesystem target +50, block device partition +40). If the risk level is Caution or higher, dd-rs prompts for confirmation. The --explain mode shows exactly what the command will do, including the data flow and risk assessment.

Performance through tiered execution

For simple copies on Linux 4.5+, dd-rs uses copy_file_range(2) for zero-copy kernel transfers, achieving 1.5–3× the speed of GNU dd. On macOS it uses fcopyfile(3). Copies needing conversions use double-buffered read/write with read-ahead, overlapping I/O with CPU. The default block size is auto-tuned to 128 KiB, eliminating the millions of syscalls per second that plague GNU dd's 512-byte default. A visual progress bar with speed and ETA is shown by default, and SIGUSR1 still provides on-demand statistics for script compatibility.

Dual syntax

Legacy key=value syntax (if=/dev/zero of=test.bin bs=1M count=100) works exactly as expected, so existing dd scripts run unchanged. Modern subcommands are also available: dd-rs copy input output, dd-rs zero disk.img --size 1G, dd-rs random key.bin --bytes 32, dd-rs wipe /dev/sdb --passes 3, dd-rs info /dev/sda, and dd-rs explain if=/dev/zero of=/dev/sda.

Full compatibility

All 16 conversions (ascii, ebcdic, ibm, block, unblock, lcase, ucase, swab, sync, sparse, noerror, notrunc, excl, nocreat, fdatasync, fsync) and all 11 I/O flags (append, direct, directory, dsync, sync, nonblock, noatime, nocache, noctty, nofollow, fullblock) are supported. Size suffixes range from the classic c, w, b to modern KiB, MiB, GiB, and even decimal suffixes like kB, MB, GB. Exit codes match GNU dd exactly, and environment variables like POSIXLY_CORRECT and RUST_LOG provide fine-grained control. dd-rs is written in memory-safe Rust with C used only for EBCDIC lookup tables — making it auditable and secure.

MacVault is a portable encrypted file store for macOS and Linux that installs as an innocuous system utility. It provides dual-layer AES-256 encryption: the underlying APFS (macOS) or LUKS (Linux) sparsebundle image is encrypted, and the manifest tracking all files is encrypted with openssl enc -aes-256-cbc -pbkdf2. When the vault is locked, there is zero trace of its contents — no plaintext files, no metadata, nothing.

A workflow designed for simplicity

mvs init creates a new vault; mvs open unlocks and mounts it. Once open, mvs add ~/Documents/tax.pdf moves files into the vault while preserving the illusion that files remain in their original location. mvs list shows tracked files, mvs show restores all files to their origin while preserving tracking, and mvs hide instantly re-hides everything back into the vault. mvs close locks and unmounts the vault, leaving no trace.

Multiple vaults, one binary

Multi-vault support allows separate vaults for different purposes — work documents, personal files, projects — each with its own passphrase. mvs vault create/use/list manages them, and each is an independent encrypted sparsebundle with its own manifest. On macOS, passphrases are securely stored in the Keychain after first use. The disguise command moves the vault to a stealthy system path like /Library/System/Extensions/.cache, blending it in with system files.

Extensibility and auditability

A plugin system executes scripts on events: place executable scripts in ~/.mvs/plugins/ named on-open, on-close, on-add, or on-remove, and they are invoked with relevant file paths. An encrypted, append-only audit log records every operation (add, remove, hide, show, restore, open, close) inside the vault, viewable with mvs log.

• Platforms: macOS natively; Linux requires cryptsetup and ext4, with automatic backend selection.
• Atomicity: atomic manifest writes prevent corruption on crash.
• Minimal footprint: no background daemon — it only runs when invoked, and requires no root privileges.
• Clean removal: the uninstall command restores everything and deletes the vault plus the binary.

crontastic is a drop-in replacement for Vixie Cron that understands plain English. You type Every Tuesday at 10am /usr/local/bin/backup.sh and it figures out the rest. Every classic cron expression, operator, special string, and edge case is preserved — a true superset of Vixie Cron with no loss of functionality.

A parser that speaks human

The natural-language parser handles over 250 distinct patterns. It understands time of day (10am, 2:30pm, noon, midnight, half past 3, quarter to 5, five past 7, ten to 8, 3 o'clock, 7 o'clock in the evening, 11 at night, 3 in the morning, around 3pm, dawn, dusk, lunchtime, dinnertime, on the hour). It handles days and dates (Monday, weekdays, weekends, business days, Monday and Wednesday, tomorrow, next Tuesday, 1st, 15th, last day of month, first Monday of the month, January 1st). It understands frequencies (every minute, every 5 minutes, every 4 hours, every 3 days, every 2 weeks, hourly, daily, weekly, monthly, yearly, biweekly, quarterly, once a day, twice a day, 3 times a day). Even one-shot relative times work (in 18 hours, in 30 minutes, 2 hours from now, after 5 minutes, in a few hours, in a couple of minutes).

Full cron compatibility

All classic cron features are supported: the full field format (minute, hour, day-of-month, month, day-of-week), operators (*, comma, hyphen, slash, ?, L, W, #), day and month names, special strings (@reboot, @yearly, @monthly, @weekly, @daily, @midnight, @hourly), and the day-of-month + day-of-week OR semantics. The system crontab format (/etc/crontab) includes the username field after the schedule.

Built-in safety checks

Dangerous schedules that run more than ~500 times per day are flagged with a warning. Overlap detection checks existing crontab entries for collisions at the same minute. Root warnings suggest using a non-privileged user, and environment checks ensure PATH contains standard system directories, SHELL is set to a known shell, and HOME is set and non-empty.

The toolchain

The --explain mode translates any schedule into English and shows the next five execution times. Cross-platform support handles macOS and Linux with correct paths, shells, and defaults. The CLI includes subcommands for edit (-e), list (-l), remove (-r), user targeting (-u), check, explain, classic output (-c), daemon mode (-d), and stdin/file input. Daemon mode runs as a persistent scheduler, reading the crontab at startup and checking every minute for jobs to execute.

macos-evilmaid documents a physical-access attack chain on macOS that can be used for either legitimate liberation or malicious compromise, depending on the user. The technique exploits Recovery Mode's unlimited privileges to install a backdoor that persists across reboots and provides root access.

The attack chain

Boot into Recovery Mode (⌘+R on Intel, hold the power button on Apple Silicon), run a simple shell script from a USB drive, reboot normally, and connect to a reverse shell listening on port 5500. From the shell, dsenableroot activates the root user with a password you control. The entire process takes minutes and requires no admin password, no user interaction, and leaves no trace of authentication.

What gets installed

The script installs a LaunchDaemon at /Library/LaunchDaemons/com.apple.networkd.plist that masquerades as a legitimate Apple service. It creates a hidden payload directory at /private/var/tmp/.systemupdate/ containing the reverse-shell agent. The LaunchDaemon specifies UserName: root, so the shell runs with full privileges before any user logs in — and before any MDM policy enforcement begins. Recovery Mode runs underneath the installed OS, so MDM profiles, configuration policies, and user restrictions simply do not exist in that environment.

Two paths, one technique

• Path 1 — The Locked-Out Owner: you own the Mac but are stuck as a standard user because an employer or school enrolled it in MDM, IT left without providing admin credentials, or you bought a second-hand Mac still MDM-bound.
• Path 2 — The Evil Maid: an attacker gains temporary physical access to a Mac they do not own. The README explicitly compares these paths, noting the legal and ethical distinctions.

Mitigations

A firmware password (Intel) or Secure Boot → Full Security (Apple Silicon) prevents booting into Recovery Mode without authentication. FileVault full-disk encryption encrypts user data, though the OS volume itself is not encrypted — combined with a firmware password, this is much stronger. MDM/endpoint monitoring can alert on new LaunchDaemons or unexpected listening ports, but only after the fact. Physical security — locking the device and never leaving it unattended — is the most effective control.

Detection for blue teams

• Unexpected plist files in /Library/LaunchDaemons/, especially with Apple naming conventions.
• Unexpected listening ports — lsof -i :5500.
• Hidden directories under /private/var/tmp/.
• dsenableroot or dscl invocations in unified logs.
• Sudden disappearance of MDM enrollment profiles.