Linux servers & infrastructure
Exposed services, SSH, sudo and file permissions, systemd units, firewall rules and privilege escalation – from attacker shell to root.
I attack your systems before someone else does.
Penetration testing with a focus on Linux infrastructure: servers, containers and Kubernetes – and the web applications running on them. AI-assisted reconnaissance, manual depth and a report your team can act on right away.
- certifications
- OSCP · SCP Web Application Security
- methodology
- BSI pentest guideline · OWASP WSTG
- offensive_since
- 2019 · bug bounty, disclosure, pentests
- reports
- German · English
01 / services
What I test
Containers & Kubernetes
Container escapes, RBAC, network policies, secrets and images: how far does an attacker get from a compromised pod?
Web application & API pentest
Manual testing following OWASP WSTG: authentication, authorization, input validation, injection and business logic.
External attack surface
What does an attacker see from the outside? Subdomains, exposed services and forgotten systems – mapped with AI, assessed by hand.
Pipeline & supply chain
Build runners, secrets, permissions, container images and dependencies: who can push what into production?
AI applications & pipelines
LLM features following the OWASP Top 10 for LLM Applications, agents with tool access, and the data and model pipeline behind them.
02 / approach
Agents map it. I go in.
AI agents gather in parallel what is publicly discoverable about your systems. Then I take over: targeted, manual and all the way to a verifiable proof. The result is a report your team can act on right away.
The animation follows a real black-box assessment – simplified and anonymised.
agents collecting
1/6
❯ ai-recon start --scope "*.[redacted].de" --agents osint,dns-enum
[*] osint: tech stack · public docs · repos dns-enum: subdomains · records
→ subdomains & technologies captured
❯ ai-recon add --agents port-scanning,service-discovery
[*] port-scanning: open ports service-discovery: banners · versions · tech
→ hosts, ports & services mapped
❯ ai-recon brief --to me && nmap -sV -sC -p 8443 $SUSPECT
[*] findings übernommen · verdächtigen dienst gezielt prüfen
→ suspicious service
❯ burpsuite --project-file=engagement.burp
[*] auth · inputs · business logic · by hand
→ sql injection + misconfiguration
❯ python3 poc.py --target svc.[redacted].de
[*] custom proof of concept · reproducible
→ remote code execution
❯ ai-report draft --findings ./loot && review
[*] agent drafts · every finding verified by hand
→ report with fixes delivered
network
Proof of concept, reproducible at any time
A concrete fix for every finding
Help closing the gaps
03 / process
From scoping to retest
-
01
Scoping
Goals, scope, test type (black, grey or white box) and time window agreed in writing.
-
02
Testing
AI-assisted reconnaissance, then manual testing. Critical findings are reported immediately, not just in the report.
-
03
Report
Management summary plus technical findings with reproduction steps, PoC and a concrete fix.
-
04
Retest
After your fixes I test again and confirm the remediation in writing.
04 / toolbox
Knowing Linux from the inside to attack it from the outside
I have worked with Linux every day since 2006 – from embedded systems in medical and camera technology to build and development servers and production Kubernetes clusters. I know the systems I attack from the inside: permissions, services, configuration and the usual shortcuts in operations. For reconnaissance and reporting I use my own agent workflows; my lab is fully reproducible, and I train regularly on HackTheBox.
offense
- Burp Suite
- OWASP ZAP
- mitmproxy
- nmap
- sqlmap
- ffuf
- nuclei
- subfinder
- httpx
- katana
- dnsx
- dalfox
- custom exploits & PoCs
ai & agents
- Claude Code
- subagents
- MCP
- own agents
- LangGraph
- Ollama
distributions
- Debian
- Ubuntu
- Red Hat
- NixOS
- Talos Linux
- Kali Linux
operations & hardening
- systemd
- auditd
- OpenSSH
- nftables
- WireGuard
- Tailscale
- own PKI / CA
- HashiCorp Vault
- Ansible
- Nix Flakes
container & cluster
- Kubernetes
- k3s
- OpenShift
- Docker
- Podman
- Helm
- ArgoCD
- RBAC
- NetworkPolicies
- Sealed Secrets
embedded linux
- Yocto / BitBake
- NXP i.MX6 / i.MX8
- QEMU
- Cross-Builds
- remote debugging & firmware updates
pipeline security
- Trivy
- SonarQube
- Renovate
- SBOM / SPDX
- secrets management
Knowledge
05 / ai-security
More than prompt injection
AI applications inherit the weaknesses of classic software and add their own. Here I explain the most important risks for LLM applications and AI pipelines – briefly, clearly and with a link to the in-depth article.
LLM applications
Risks in applications built on language models-
Prompt injection
Inputs – typed directly or hidden in documents, web pages and emails – make a model ignore its instructions or follow someone else’s.
Read more → -
Excessive agency
An agent can do more than its task requires: too many tools, too broad permissions, too little human confirmation.
Read more → -
Data and model poisoning
Manipulated training, fine-tuning or embedding data deliberately change how a model behaves.
Read more →
AI pipelines
From the data to the inference endpoint-
Agents & tool access
MCP servers, tool permissions and automation decide what a manipulated agent can actually do.
Read more → -
Model supply chain
Provenance and integrity of models, weights and dependencies – including registries and unsafe file formats.
Read more → -
Inference infrastructure
Model servers and APIs are services like any other: exposed, often weakly isolated, rarely rate-limited.
Read more →