I'm a penetration tester. I test enterprise networks, cloud environments, and web applications. And I build frameworks because I got tired of the gap between how security tools work and how adversaries actually operate.

Most security tools answer one question: is this vulnerable? That's useful, but it's not how attacks work. An attacker doesn't run a scanner, file a report, and go home. They take the SSRF finding from hour one, use it to pull cloud credentials from IMDS, escalate those credentials through misconfigured IAM policies, and by hour four they're downloading production databases from S3.

The problem I kept hitting during engagements was context loss between attack phases. You discover a JWT with weak signing in one tool, then manually copy it into another tool to test IDOR. You harvest AWS credentials via SSRF, then switch to a completely different framework for privilege escalation. Every tool switch is a context switch. Every context switch is where findings get lost and attack chains break.

That's the problem these 13 platforms solve. Each one owns a complete attack surface. Each one carries discovered credentials, tokens, and findings from one module to the next through a shared EngagementSession. The JWT forged in the auth module is the same token used to probe IDOR endpoints. The credentials harvested from IMDS flow directly into IAM privilege escalation — no clipboard, no glue scripts, no context loss.

Every framework makes tradeoffs. These are mine and why I made them.

Python, not Go or Rust. Not a performance decision — an adoption decision. Security teams read Python. When a finding needs manual verification during an engagement, the operator shouldn't need to learn a new language to understand the detection logic. The tradeoff is clear: these tools won't outperform compiled scanners on raw throughput. But throughput isn't the bottleneck in a real engagement — context loss is.

13 separate packages, not a monorepo. Each platform targets a different assessment type with different authorization boundaries. A client who authorizes web application testing shouldn't need to install Active Directory attack modules on their network. Separate packages mean separate scopes, separate dependencies, and cleaner authorization documentation.

EngagementSession as the core abstraction. Traditional security tools are stateless: scan, output, done. Real engagements are stateful — what you discover in phase one determines what you test in phase two. Every platform is built around a session object (EngagementSession or EngagementContext) that wraps an HTTP session with retry logic and carries cookies, tokens, discovered credentials, and confirmed findings across all modules. This is what makes attack chaining possible without manual glue.

Module registry pattern across all platforms. Every platform uses the same dispatch: a MODULE_REGISTRY dict mapping names to classes, a BaseModule ABC, and a CLI that accepts --modules all or --modules ssrf auth. An operator who learns one platform already knows all thirteen. New attack techniques drop in as modules without touching CLI or reporting code.

These aren't 13 isolated tools. They map to the stages of adversary simulation:

Recon ──→ Initial Access ──→ Credential Access ──→ Privilege Escalation ──→ Lateral Movement ──→ Persistence ──→ Exfiltration

Specialized surfaces — Tempest (wireless), Pulse (mobile), Forge (physical/hardware) extend coverage to engagement types beyond the standard network kill chain.

Training — SecurityQuestAcademy is a separate project: 700 hands-on challenges across 7 domains with an interactive terminal game engine.

• Hardening the platform suite — integration tests, engagement demos, and benchmarks against established tools
• Writing an offensive security methodology book in Persian — structured adversary simulation for the regional security community
• Researching cloud attack path chaining across IAM, compute, and storage layers

Open to offensive security and red team engineering roles in Germany and Europe.