scriptoriumadmin/strix
1
0
Fork 0
mirror of https://github.com/usestrix/strix.git synced 2026-08-28 05:25:00 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Merge 5a34df9786 into cbb0f57058

Browse source
This commit is contained in:
Sandiyo Christan 2026-08-27 20:22:21 +00:00 • committed by GitHub
commit f7647b4cd8
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
3 changed files with 425 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

145
strix/skills/custom/safe_mode_crawling.md Normal file
View file

@ -0,0 +1,145 @@
---
name: safe-mode-crawling
description: Systematic guard against destructive side effects when crawling and testing — recognize irreversible operations before invoking them, prefer read-only reconnaissance, and surface high-risk actions to the operator
---
# Safe-Mode Crawling Guard
Autonomous agents that drive browsers, submit forms, and fire HTTP requests can cause real damage to target environments — deleting data, triggering payments, sending emails, or mutating production state. This skill teaches agents to recognize destructive operations **before** executing them, prefer read-only reconnaissance, and escalate to the operator when an action's side effects are uncertain.
## Why This Matters
An agent pointed at a staging or production application with admin credentials can:
- `DELETE` database records, user accounts, or storage objects
- Trigger email/SMS notifications to real users
- Process payments or refunds through payment gateways
- Reset passwords, revoke API keys, or invalidate sessions
- Execute bulk operations (purge caches, drop tables, wipe logs)
- Submit forms that create real orders, tickets, or support requests
These are not hypothetical — they are the natural consequence of an autonomous agent exploring admin panels and API endpoints without constraint.
## Recognizing Destructive Operations
### HTTP Method Heuristics
| Method | Default Risk | Notes |
|--------|-------------|-------|
| `GET`, `HEAD`, `OPTIONS` | 🟢 Usually Safe | Read-only by specification, but **not guaranteed** — some apps use GET for state changes |
| `POST` | 🟡 Caution | Creates resources; may trigger side effects |
| `PUT`, `PATCH` | 🟡 Caution | Modifies existing resources |
| `DELETE` | 🔴 High Risk | Removes resources; often irreversible |
**Critical:** HTTP method alone is NOT sufficient to determine safety. Some applications expose state-changing operations through `GET` (e.g., `GET /api/users/delete?id=5`, `GET /admin/reset-password?user=admin`, `GET /logout`, `GET /unsubscribe`). Similarly, `POST` is used for destructive operations (e.g., `POST /api/users/delete`, `POST /admin/purge-cache`). **Always check endpoint semantics — URL path, query parameters, and context — regardless of HTTP method.**
### High-Risk Endpoint Patterns
Watch for these patterns in URLs, form actions, and API routes:
**Deletion / Removal**
- `/delete`, `/remove`, `/destroy`, `/purge`, `/wipe`, `/drop`
- `/api/*/delete`, `/admin/*/remove`
- Bulk variants: `/bulk-delete`, `/delete-all`, `/clear-all`
**State Mutation**
- `/reset`, `/revoke`, `/invalidate`, `/deactivate`, `/disable`
- `/password/reset`, `/api-keys/revoke`, `/sessions/invalidate`
**Financial / Transactional**
- `/payment`, `/charge`, `/refund`, `/purchase`, `/checkout`
- `/subscribe`, `/cancel-subscription`, `/billing`
**Communication Triggers**
- `/send`, `/notify`, `/email`, `/sms`, `/webhook/trigger`
- `/invite`, `/broadcast`, `/publish`
**Admin / System**
- `/admin/*/execute`, `/admin/*/run`
- `/migrate`, `/seed`, `/truncate`, `/backup/delete`
### Form Analysis
Before submitting any form, check:
1. **Action URL** — does it match a high-risk pattern above?
2. **Submit button text** — "Delete", "Remove", "Reset", "Send", "Pay", "Confirm"
3. **Confirmation dialogs** — JavaScript confirms are a signal the app considers the action risky
4. **Hidden fields** — `_method=DELETE`, `action=destroy`, `confirm=true`
5. **CSRF tokens** — presence indicates state-changing operation
## Decision Framework
```
1. Does the endpoint match a high-risk pattern (e.g., /delete, /payment, /reset)?
├── YES → STOP. Log the finding. Do NOT execute.
│ Surface to operator with: URL, method, parameters, and risk assessment.
└── NO → Continue to step 2.
2. Does the endpoint semantics suggest state change? (Check URL path, query params,
button text, form action, API docs — even for GET/HEAD/OPTIONS.)
├── YES or UNCERTAIN → Treat as mutating. Go to step 3.
└── NO, confirmed read-only → Proceed.
3. Can this action be reversed?
├── YES (e.g., create a test user that can be deleted) → Proceed with caution.
└── NO or UNCERTAIN → STOP. Surface to operator.
```
> **Why GET/HEAD/OPTIONS are not auto-approved:** The HTTP spec says these methods _should_ be safe, but real-world applications violate this. A `GET /admin/deleteUser?id=5` is just as destructive as `DELETE /api/users/5`. The decision tree checks endpoint semantics for **every** request, regardless of method.
## Operational Rules
### Before Any Mutating Request
1. **Identify the operation** — What does this endpoint actually do? Read the endpoint name, form labels, button text, and API documentation if available.
2. **Assess reversibility** — Can the action be undone? Creating a test record is usually reversible; deleting a production record is not.
3. **Check scope** — Is this a single-resource operation or a bulk operation? Bulk operations are categorically higher risk.
4. **Prefer read-only alternatives** — Can the same vulnerability be demonstrated with a GET-based information disclosure instead of a destructive POST?
### Idempotency Checks
Before repeating any mutating request:
- Has this exact request already been sent in this session?
- Did the first attempt succeed? If so, do not retry — the side effect has already occurred.
- For test data creation: use unique, identifiable values (e.g., `strix_test_<timestamp>`) so cleanup is possible.
### When to Stop and Surface
**Always stop and report to the operator when:**
- The action would delete or modify real user data
- The action would trigger external communication (email, SMS, webhook)
- The action involves payment processing or financial transactions
- The action would modify authentication state (password reset, key revocation)
- The action is a bulk/batch operation affecting multiple resources
- You are uncertain about the side effects
**Format for surfacing:**
```
⚠️ HIGH-RISK ACTION DETECTED
Endpoint: DELETE /api/v1/users/42
Method: DELETE
Risk: Irreversible deletion of user account
Context: Found during IDOR testing on user management panel
Recommendation: Test with a disposable test account instead, or confirm with operator
```
## Validation
1. Demonstrate that the safe-mode guard prevents execution of destructive operations by showing the agent correctly identifies and skips high-risk endpoints
2. Confirm that read-only testing paths still discover the vulnerability (e.g., proving IDOR via GET before attempting DELETE)
3. Document any high-risk operations that were surfaced to the operator instead of executed
4. Verify that test data created during scanning uses identifiable prefixes for cleanup
## Integration with Other Skills
- **IDOR testing** — Prove authorization bypass with GET requests first; only attempt state-changing operations with disposable test data
- **CSRF testing** — Demonstrate the vulnerability exists without actually triggering the destructive action on real data
- **Business logic** — Map the workflow read-only before attempting to exploit state transitions
- **Authentication/JWT** — Test token manipulation without invalidating real sessions
## Pro Tips
1. Start every engagement by mapping the application **read-only** — enumerate endpoints, understand data model, identify admin functions — before attempting any writes
2. If the target has a test/sandbox mode, prefer it over production endpoints
3. When testing APIs, use obviously fake data (`test@strix-pentest.example`, `strix_test_*`) so the operator can identify and clean up agent-created records
4. Document every mutating request you *choose not to send* — this is valuable information for the operator and demonstrates responsible testing methodology
5. A vulnerability that could cause damage is still a valid finding even if you don't trigger the damage — describe the attack path, show the preconditions are met, and let the operator decide on full exploitation

110
strix/skills/protocols/smb_netbios_enumeration.md Normal file
View file

@ -0,0 +1,110 @@
---
name: smb-netbios-enumeration
description: SMB/NetBIOS enumeration covering null sessions, share discovery, user enumeration, and known protocol vulnerabilities (e.g., EternalBlue, SMBGhost)
---
# SMB/NetBIOS Enumeration
Server Message Block (SMB) and NetBIOS are critical attack surfaces on Windows networks (and Samba on *nix). Misconfigured SMB can expose file shares, user lists, password policies, and domain information. Vulnerable SMB versions (SMBv1) or unpatched SMBv3 implementations can lead to unauthenticated remote code execution.
## Attack Surface
**Scope**
- TCP 445 (Direct SMB over TCP)
- TCP 139 (SMB over NetBIOS)
- UDP 137 (NetBIOS Name Service)
- UDP 138 (NetBIOS Datagram Service)
**What to Test**
- Authentication requirements (Null session, Guest access)
- Share permissions (Read/Write access on IPC$, C$, ADMIN$, custom shares)
- Information disclosure (Users, groups, domain info, password policies)
- Vulnerability to known RCE/DoS flaws (MS17-010, CVE-2020-0796)
- Message signing configuration (SMB relay susceptibility)
## Key Vulnerabilities
### Null Sessions and Guest Access
**Anonymous Enumeration**
Historically, Windows allowed "Null Sessions" (anonymous access without credentials) to IPC$. This permits enumeration of users, groups, shares, and password policies. While restricted in modern Windows versions by default, misconfigurations or legacy systems still exhibit this.
**Guest Access**
The built-in Guest account might be enabled and have access to shares, leading to sensitive data exposure.
### Protocol Vulnerabilities
| Vuln | CVE | Description | Test |
|------|-----|-------------|------|
| EternalBlue | MS17-010 / CVE-2017-0144 | RCE in SMBv1. Exploited widely (WannaCry). | `nmap --script smb-vuln-ms17-010 -p 445 <host>` |
| SMBGhost / CoronaBlue | CVE-2020-0796 | RCE/DoS in SMBv3.1.1 compression. | `nmap --script smb-vuln-cve-2020-0796 -p 445 <host>` |
| SMBleed | CVE-2020-1206 | Information disclosure in SMBv3.1.1 decompression. | Often tested alongside SMBGhost. |
### SMB Message Signing
**SMB Relay Attacks**
If SMB signing is not required (`Message signing enabled but not required`), the server is vulnerable to SMB relay attacks. An attacker can intercept NTLM authentication traffic and relay it to the server to gain unauthorized access.
## Testing Methodology
### 1. Protocol and Configuration Check
```bash
# General SMB discovery and signing check
nmap -n -Pn -p 139,445 --script smb-os-discovery,smb-security-mode <host>
```
### 2. Null Session and Share Enumeration
```bash
# Using smbclient (anonymous)
smbclient -N -L //<host>
# Using enum4linux (comprehensive enumeration)
enum4linux -a <host>
# Using nmap for shares
nmap -n -Pn -p 445 --script smb-enum-shares <host>
```
### 3. Vulnerability Scanning
```bash
# Check for known SMB vulnerabilities
nmap -n -Pn -p 445 --script "smb-vuln-*" <host>
```
## Validation
1. **Demonstrate Access** — Show the output of an anonymous/guest connection listing shares or reading a file.
2. **Prove Enumeration** — Extract valid usernames or password policy details using a null session.
3. **Confirm Vulnerabilities** — Run specific vulnerability checks (e.g., MS17-010) and verify the output indicates vulnerability.
## False Positives
- **Firewall Filtering** — Ports appear open, but deep inspection or scripts fail due to intermediate firewalls.
- **SMB Signing "Enabled"** — The service might support signing, but if it's not *required*, it's still vulnerable to relay. Pay attention to the exact wording.
- **Honeypots** — Deliberately vulnerable-looking SMB services that trap scanners.
## CVSS Context
| Finding | Typical CVSS | Rationale |
|---------|-------------|-----------|
| EternalBlue (MS17-010) | 9.3 (Critical) | Remote Code Execution |
| SMBGhost (CVE-2020-0796) | 10.0 (Critical) | Remote Code Execution |
| Anonymous Share Access (Read/Write) | 7.5 - 9.0 (High/Critical) | Data exposure or modification depending on share content |
| Null Session User Enumeration | 5.3 (Medium) | Information disclosure aiding further attacks |
| SMB Signing Not Required | 5.3 (Medium) | Enables relay attacks, requiring adjacent network position |
## Pro Tips
1. When testing shares, look for configuration files, backups, and scripts that might contain hardcoded credentials.
2. `IPC$` is for inter-process communication; you can't typically browse files on it, but it's used for enumeration.
3. If anonymous access fails, always test with any valid credentials you've obtained, no matter how low-privileged.
## Tooling
- **nmap** — Essential for discovery and vulnerability checks (`smb-os-discovery`, `smb-enum-shares`, `smb-vuln-*`).
- **smbclient** — Command-line SMB client, excellent for testing connectivity and manual browsing.
- **enum4linux** — Comprehensive tool for extracting information from Windows and Samba hosts.
- **CrackMapExec / NetExec** — Advanced post-exploitation and enumeration tools (if available in the environment).

170
strix/skills/protocols/ssl_tls_analysis.md Normal file
View file

@ -0,0 +1,170 @@
---
name: ssl-tls-analysis
description: SSL/TLS configuration assessment covering cipher suite enumeration, certificate chain validation, protocol downgrade attacks, and known implementation vulnerabilities
---
# SSL/TLS Configuration Analysis
SSL/TLS misconfigurations remain among the most common network-layer findings. Weak cipher suites, expired certificates, protocol downgrade vulnerabilities, and implementation flaws expose encrypted communications to interception, decryption, and man-in-the-middle attacks.
## Attack Surface
**Scope**
- Any service exposing TLS: HTTPS (443), SMTPS (465/587), IMAPS (993), LDAPS (636), database TLS, custom ports
- Load balancers, reverse proxies, CDN edge nodes (each may have independent TLS configuration)
- Internal services using self-signed or improperly chained certificates
**What to Test**
- Protocol versions supported (SSLv3, TLS 1.0/1.1/1.2/1.3)
- Cipher suite selection and ordering
- Certificate validity, chain completeness, and trust anchoring
- Key exchange strength and forward secrecy
- Known implementation vulnerabilities (BEAST, POODLE, Heartbleed, ROBOT, etc.)
- HSTS, certificate transparency, OCSP stapling configuration
## Key Vulnerabilities
### Protocol Downgrade
**Legacy Protocol Support**
- SSLv3 → POODLE attack (CVE-2014-3566); padding oracle on CBC ciphers
- TLS 1.0 → BEAST attack (CVE-2011-3389); CBC IV predictability
- TLS 1.1 → No known critical attacks but lacks modern security features; deprecated by RFC 8996
**Detection**
```bash
# Check for SSLv3 support
nmap --script ssl-enum-ciphers -p 443 <host> | grep -i "SSLv3"
# Or with openssl
openssl s_client -ssl3 -connect <host>:443 2>&1 | grep -i "alert"
```
### Weak Cipher Suites
**Critical Weaknesses**
- `NULL` ciphers — no encryption at all
- `EXPORT` ciphers — 40/56-bit keys; trivially breakable (FREAK, Logjam)
- `RC4` ciphers — biased keystream; practical plaintext recovery (CVE-2013-2566)
- `DES`/`3DES` — 56/112-bit effective; Sweet32 birthday attack (CVE-2016-2183)
- `CBC` mode without TLS 1.3 — vulnerable to padding oracle attacks in older implementations
**No Forward Secrecy**
- `RSA` key exchange (not `ECDHE`/`DHE`) — compromised server key decrypts all past traffic
- Static `DH` parameters — precomputed logjam tables for common 1024-bit groups
### Certificate Issues
**Chain Problems**
- Expired certificate or intermediate
- Self-signed certificate in production
- Incomplete chain (missing intermediates)
- Wrong hostname (CN/SAN mismatch)
- Revoked certificate (CRL/OCSP)
**Key Weakness**
- RSA key < 2048 bits
- ECDSA key < 256 bits (P-256)
- SHA-1 signed certificates (deprecated since 2017)
### Implementation Vulnerabilities
| Vuln | CVE | Test |
|------|-----|------|
| Heartbleed | CVE-2014-0160 | `nmap --script ssl-heartbleed -p 443 <host>` |
| POODLE | CVE-2014-3566 | Check for SSLv3+CBC support |
| ROBOT | CVE-2017-13099 | `nmap --script ssl-robot -p 443 <host>` (if script available) |
| DROWN | CVE-2016-0800 | Check for SSLv2 support on any server sharing the RSA key |
| CCS Injection | CVE-2014-0224 | `nmap --script ssl-ccs-injection -p 443 <host>` |
| CRIME/BREACH | CVE-2012-4929 | Check TLS compression; `Accept-Encoding: gzip` response analysis |
| Renegotiation | CVE-2009-3555 | `openssl s_client -connect <host>:443` then type `R` |
## Testing Methodology
### 1. Enumerate Supported Protocols and Ciphers
```bash
# Comprehensive nmap scan
nmap -n -Pn --script ssl-enum-ciphers -p 443,8443 <host>
# Quick openssl check for specific protocol
openssl s_client -tls1 -connect <host>:443 < /dev/null 2>&1
openssl s_client -tls1_1 -connect <host>:443 < /dev/null 2>&1
openssl s_client -tls1_2 -connect <host>:443 < /dev/null 2>&1
openssl s_client -tls1_3 -connect <host>:443 < /dev/null 2>&1
```
### 2. Inspect Certificate Chain
```bash
# Full certificate details
openssl s_client -connect <host>:443 -showcerts < /dev/null 2>&1 | openssl x509 -noout -text
# Check specific fields
openssl s_client -connect <host>:443 < /dev/null 2>&1 | openssl x509 -noout \
-subject -issuer -dates -fingerprint -ext subjectAltName
```
### 3. Test for Known Vulnerabilities
```bash
# Heartbleed
nmap -n -Pn --script ssl-heartbleed -p 443 <host>
# CCS Injection
nmap -n -Pn --script ssl-ccs-injection -p 443 <host>
# Multiple checks in one pass
nmap -n -Pn --script "ssl-*" -p 443 <host>
```
### 4. Check Security Headers
```bash
# HSTS header
curl -sI https://<host> | grep -i strict-transport
# Expected: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
```
## Validation
1. **Demonstrate the weakness** — Show the specific weak protocol/cipher is negotiable, not just advertised
2. **Prove impact** — For protocol downgrade, show the client can be forced to use the weak protocol; for weak ciphers, confirm the server selects them when offered exclusively
3. **Certificate issues** — Show the exact chain failure (expired date, hostname mismatch, missing intermediate)
4. **Implementation vulns** — Confirm with Nmap NSE scripts or equivalent tool output
5. **Rate accurately** — TLS 1.0 support alone is Medium; combine with CBC ciphers for High; SSLv3 or Heartbleed is Critical
## False Positives
- Server advertises weak ciphers but never selects them (server preference enforced) — verify by offering only the weak cipher
- Certificate expired in alternate SAN but primary domain is valid
- CDN/WAF terminates TLS before reaching origin — the finding applies to the edge, not the origin
- HSTS missing on a non-browser API endpoint — lower severity than a user-facing site
- TLS 1.0 enabled but only for specific legacy clients behind a load balancer policy
## CVSS Context
| Finding | Typical CVSS | Rationale |
|---------|-------------|-----------|
| SSLv3 enabled + CBC ciphers (POODLE) | 7.5 (High) | Network-exploitable padding oracle |
| TLS 1.0 only (no TLS 1.2/1.3) | 5.3 (Medium) | Deprecated protocol, known weaknesses |
| Heartbleed (confirmed) | 9.1 (Critical) | Memory disclosure, key extraction |
| Self-signed cert in production | 5.9 (Medium) | No trust chain; enables MITM |
| Missing HSTS | 4.3 (Medium) | Protocol downgrade on first visit |
| Weak DH parameters (< 2048 bit) | 5.3 (Medium) | Logjam precomputation feasible |
| No forward secrecy (RSA key exchange) | 5.3 (Medium) | Past traffic decryptable if key leaked |
## Pro Tips
1. Always test all TLS-enabled ports, not just 443 — SMTP STARTTLS (587), database TLS, and custom service ports often have weaker configurations
2. Check if the same RSA key is shared across multiple services — one SSLv2 service enables DROWN on all of them
3. For CDN-fronted targets, also test the origin directly if accessible — CDN may mask origin TLS weaknesses
4. Certificate transparency logs (crt.sh) can reveal additional subdomains and cert history
5. Modern TLS 1.3 has no known cipher suite weaknesses — if the server supports only TLS 1.3, focus testing on certificate chain and implementation instead
## Tooling
- **nmap** (preinstalled) — `ssl-enum-ciphers`, `ssl-heartbleed`, `ssl-ccs-injection` NSE scripts
- **openssl** (preinstalled) — Protocol probing, certificate inspection, manual cipher testing
- **nuclei** (preinstalled) — TLS misconfiguration templates: `nuclei -u https://<host> -tags ssl,tls`