Projects

Problem

Cloud security teams often have the telemetry they need, but not the connective tissue that turns raw events into a usable incident story. The hard part is not collecting data. It is normalizing it, correlating it, explaining why a detection fired, and giving an analyst a next step that does not waste time.

Approach

Ingests CloudTrail, GuardDuty, and Security Hub samples, normalizes them into a common event model, runs defensive detections, correlates suspicious activity, and generates analyst-ready findings, timelines, and manager summaries.

Highlights

• Root account usage
• Console login without MFA
• Privileged AssumeRole
• CloudTrail tampering
• Public sensitive port exposure
• GuardDuty plus CloudTrail corroboration

Problem

LLM applications are often deployed without rigorous security testing against prompt injection or sensitive data leakage. Traditional scanners aren't built for the non-deterministic nature of model responses.

Approach

A scanner that probes LLM endpoints with specialized payloads and runs the responses through YAML-defined detectors mapped to the OWASP Top 10 for LLMs.

Highlights

• Prompt injection (direct/indirect)
• Sensitive data disclosure (PII, secrets)
• Output handling (XSS, SQLi injection)
• Jailbreak detection
• Resource abuse & token exhaustion
• SIEM-ready JSON logging

Problem

Cloud security scanners find misconfigurations in isolation. They don't tell you which 5 of those 200 findings chain together into an actual account compromise path.

Approach

Models IAM principals and resources as a directed graph. Finds multi-step privilege escalation paths across service boundaries by matching chains against 12+ built-in attack tactics.

Highlights

• PassRole + Lambda/EC2/Glue
• IMDS credential theft
• Confused Deputy via S3 triggers
• IAM policy self-escalation
• Lambda code hijack
• Policy version rollback

Problem

Static shellcode runners are easily detected. Manual encryption and evasion patching is tedious and error-prone during OSEP-style engagements.

Approach

An advanced generator that applies stackable encryption layers (XOR, AES, RC4) and runtime evasion patches (AMSI/ETW) to shellcode using a standardized Jinja2 template engine.

Highlights

• Stackable encryption (XOR, AES, RC4, Caesar)
• AMSI & ETW runtime patching
• 9+ Output formats (EXE, DLL, VBA, HTA, PS1, JS, MSBuild)
• RW -> RX memory allocation safety
• Randomized namespaces and class names
• SQLite tracking of generated payloads

Problem

Running Claude Code against a local model means picking a quantization that fits your VRAM, configuring environment variables, and verifying both ends agree on the protocol. The setup gap is what stops most people from trying it.

Approach

Detects GPU, CPU, and RAM, picks a model that fits the available memory, downloads it via Ollama, and writes the Claude Code environment variables. The installer verifies the release tarball against the SHA256SUMS asset before extracting.

Highlights

• Hardware detection (GPU, VRAM, system RAM)
• Model selection that fits available memory
• Cross-platform installer (Linux, macOS, Windows, WSL2)
• SHA256-verified release tarball
• Idempotent re-runs (safe to re-install)
• Zero Python dependencies (pure shell)